Les systèmes occupés sur un réseau utilisé par plusieurs utilisateurs locaux (ou des milliers d'utilisateurs Web) rencontrent des problèmes de performances au cours de leur cycle de vie. Seuls les systèmes qui ne sont pas occupés sont à l'abri des problèmes de performances qui nous tourmentent tous. Cet article explore les suspects habituels pour trouver et résoudre les problèmes de performances.
Vous trouverez ci-dessous des consignes génériques, un résumé de base des "points de départ". Chaque problème est différent, mais au fur et à mesure que vous acquérez de l'expérience, vous aurez une meilleure idée d'où et comment commencer à rechercher un problème particulier. Je crois que vous pouvez apprendre les bases du dépannage, mais vous ne pouvez pas apprendre l'expérience ou l'intuition. Ces deux viennent avec le temps. Notez également que certains problèmes se manifestent de telle manière que vous commencez par un chemin et que vous êtes souvent conduit à un autre. Ce facteur est frustrant mais normal. Par exemple, certains problèmes de disque peuvent entraîner une augmentation de l'utilisation de votre processeur, et des problèmes de mémoire peuvent se masquer en tant que problèmes de performances du disque. Commencez d'abord par les choses faciles, puis progressez vers les plus complexes. Ne vous compliquez pas la vie plus que nécessaire. Parfois, il vous suffit de remplacer un câble réseau ou de redémarrer un système. Simple, mais efficace.
Annuler les modifications récentes
Apporter des changements dans un environnement de production est nécessaire. La documentation de ces changements est obligatoire. Vous serez content de l'avoir fait en cas de problème, et ce sera le cas. La chose étrange à propos des modifications sur Linux (ou tout autre système) est que la modification elle-même peut parfaitement fonctionner lorsque vous la faites, mais en un jour ou deux, les performances de votre système en souffrent. Avant de faire quoi que ce soit d'autre, vérifiez votre documentation de modification pour voir si des modifications récentes ont été apportées au système. Les modifications incluent les correctifs logiciels, les mises à jour de toutes sortes, les remplacements ou mises à niveau de matériel, les mises à jour de pilotes, les mises à jour de micrologiciels, les envois de code, les nouvelles installations de logiciels et les modifications de configuration.
Lorsque vous consultez la documentation de vos modifications, comparez les modifications récentes avec les problèmes que vous rencontrez. Après avoir effectué les vérifications habituelles du système, vous devez annuler vos modifications une par une pour voir laquelle peut être attribuée à la cause première de vos performances. Parfois, vous constaterez que certains "clusters" de mise à jour ne sont pas compatibles ou doivent être installés ou appliqués dans un ordre particulier. Vérifiez toujours la documentation de votre fournisseur pour voir si c'est le cas.
Mettre à jour, mettre à jour, mettre à jour
Vous pouvez éviter les problèmes de performances associés aux bogues logiciels et matériels en gardant tout à jour, en particulier en ce qui concerne les logiciels côté serveur (plutôt que côté client, comme un navigateur Web). Le côté client doit également être mis à jour, bien sûr, mais c'est une autre discussion.
Oui, c'est un travail à plein temps de maintenir tous vos systèmes à jour. Il y a toujours quelque chose qui doit être mis à jour sur un système :le BIOS, le micrologiciel, les pilotes, le système d'exploitation, les applications, les agents, les logiciels de sécurité, les bases de données, les logiciels de sauvegarde, etc. Cette tâche ne se termine jamais. Décidez à quelle fréquence vous devez mettre à jour ou respectez la politique de correctifs de votre organisation pour planifier, programmer et appliquer ces mises à jour. Dans l'un de mes boulots, on patchait une fois par semaine. C'était une douleur. Cela nous obligeait à passer une nuit blanche une fois par semaine, ce qui vieillit vite. Cependant, il est impossible d'éviter de le faire régulièrement. Vous devez effectuer la mise à jour pour vous assurer que vos systèmes sont sécurisés et disposent des derniers correctifs de stabilité.
Si vos systèmes sont à jour et qu'aucune mise à jour plus récente n'est disponible, vous pouvez généralement exclure les mises à jour et les correctifs comme cause première d'un problème de performances.
Limites et pannes matérielles
D'après mon expérience, tout le monde (programmeurs, administrateurs réseau, direction et fournisseurs) veut blâmer l'infrastructure pour tous les problèmes de performances. Ils croient tous collectivement que l'infrastructure est le maillon le plus faible et que c'est là que les pannes sont les plus susceptibles de se produire, vous devrez donc prouver que ce n'est pas votre matériel qui cause le problème avant que quiconque n'agisse. Je suis d'accord sur un point, mais c'est un peu ennuyeux quand c'est la première hypothèse, plutôt que celle qui est étudiée simultanément avec d'autres causes potentielles.
Il existe généralement quatre composants matériels qui peuvent tomber en panne ou atteindre des limites susceptibles de vous causer des problèmes :le processeur, le réseau, la mémoire et le disque. D'autres composants peuvent également tomber en panne, comme les blocs d'alimentation, mais ces "quatre grands" sont les coupables les plus courants et les premiers endroits où vous devriez regarder en cas de problème.
Processeur
De nos jours, la plupart des systèmes de serveurs ont des banques de processeurs multicœurs et multiprocesseurs. Si vous avez un problème de CPU, cela peut être dû à un défaut du CPU lui-même. Trouver le processeur spécifique qui vous pose problème dépasse le cadre de cet article. Si vous soupçonnez une panne ou une anomalie réelle du processeur, appelez le fournisseur de votre système pour obtenir des conseils. Il est probable qu'ils aient des routines de diagnostic que vous pouvez exécuter et qui identifieront le processeur problématique. Au-delà, ils enverront un technicien pour remplacer un processeur ou tous.
Donc, à part une panne totale du processeur, que recherchez-vous lorsque vous soupçonnez un problème de processeur ? Vérifiez top pour voir si des processus surchargent votre ou vos CPU. Pour trier top pour le processeur, exécutez top puis tapez P (Maj+P). Examinez les processus qui brûlent vos cycles de processeur. Ceux qui se trouvent en haut de la liste sont-ils liés au système ou aux applications ? S'il s'agit de processus système, vérifiez votre disponibilité. Le temps de disponibilité ne devrait pas être extrêmement élevé en raison d'un redémarrage régulier.
Si vous trouvez une application particulière utilisant un nombre anormal de cycles de processeur, redémarrez l'application pour voir si le problème persiste. Si le processus est lié au système, essayez de le redémarrer si possible. Si ce n'est pas le cas, redémarrez le système. Oui, redémarrez le système.
Bonus de dépannage (redémarrage)
Oui, vous devez redémarrer au moins une fois par mois. Je sais qu'il existe une multitude d'arguments à propos de cette pratique, mais pour exclure de nombreux problèmes, un bon redémarrage résout de nombreux problèmes et vous aide à diagnostiquer les problèmes matériels avec un minimum d'effort. La mise hors tension occasionnelle du système est également une bonne pratique, car la mise en place d'un système à partir d'un démarrage à froid peut identifier de nombreux problèmes matériels susceptibles de se cacher sur un système en cours d'exécution. Vous pourrez également réduire les problèmes si le problème de performances persiste après un redémarrage.
Mémoire
L'autre aspect le plus évident à examiner lors du dépannage des performances est l'utilisation de la mémoire. Les problèmes de mémoire peuvent se manifester de différentes manières qui masquent le fait que la mémoire est en effet le problème. Si vous constatez qu'au cours d'une journée, la mémoire de votre système est épuisée, la première chose à vérifier est votre journalisation. Je sais que cela semble fou, mais la capture de journaux a presque coûté des millions de dollars à une entreprise avec laquelle je travaillais. J'ai remarqué dans les rapports de performances que la mémoire de notre système de cluster était épuisée pendant la journée. Il y avait beaucoup de gigaoctets de mémoire disponibles, ce problème n'aurait donc pas dû se produire. De plus, les performances se sont détériorées au fil de la journée. Chaque nuit à minuit, tout revenait. Que s'est-il passé à minuit, demandez-vous ? Rotation des journaux. Apparemment, quelqu'un avait activé le débogage des journaux, ce qui signifiait que des dizaines de gigaoctets par jour étaient collectés, sauvegardés et stockés inutilement. Et cela vidait notre mémoire. Une fois découvertes et corrigées, les performances sont revenues en force et ont évité de devoir dépenser des millions de dollars en systèmes supplémentaires pour cet énorme cluster.
Vous devriez également regarder l'espace d'échange si vous suspectez un problème de mémoire. Dans cette sortie, mon système est inactif donc le résultat n'est pas dramatique. Utilisez le free -m commande pour vérifier l'utilisation de la mémoire physique et virtuelle (swap) :
$ free -m
total used free shared buff/cache available
Mem: 821 200 288 10 333 484
Swap: 0 0 0
Si vous utilisez beaucoup de swap, votre système peut faire ce que les administrateurs *nix appellent le "thrashing". Le thrashing, contrairement à ce que font les skateurs, est une mauvaise chose pour nous. Vous ne voulez pas que votre système s'effondre. Le thrashing peut également apparaître comme un problème de disque s'il est suffisamment grave. Si votre système est tellement occupé à paginer qu'il affecte les performances du disque, vous devez agir immédiatement en redémarrant le processus incriminé. Maintenant, ne vous méprenez pas. Swap est configuré et configuré pour paginer des éléments sur le disque, mais lorsqu'il provoque un problème de performances, ce problème doit être résolu.
De nombreux systèmes modernes ont tellement de mémoire que l'échange sur disque n'est pas du tout utilisé. Certains administrateurs pensent que c'est un gaspillage d'espace disque. Pour moi, la configuration de l'échange dépend de l'objectif du système et de la quantité de RAM dont il dispose. Les considérations d'échange sont vraiment pour un autre article, mais je dirai que la façon dont vous gérez l'échange dépend de vous. Je ne pense plus que l'ancienne règle de 1,5 x RAM soit une bonne formule. Pensez-y. Si votre système dispose de 128 Go de RAM, cela signifie que vous configurez 192 Go de RAM pour l'espace d'échange. Ridicule. Je pourrais configurer 16 Go au maximum pour ce système si je configurais le swap.
Dans de rares cas, votre RAM peut être mauvaise ou mal fonctionner. Ça m'est arrivé. Vous devez également faire attention au type de RAM que vous achetez pour un système si vous effectuez une mise à niveau. Faites correspondre ce que vous avez ou remplacez tout si vous ne pouvez pas le faire correspondre. Ne mélangez pas les vitesses, les caches ou les marques. Utilisez également le type de RAM recommandé pour votre système. L'utilisation de RAM hors marque ou inadaptée est un désastre imminent.
Enfin, les programmes errants peuvent causer des problèmes de mémoire. Les programmes basés sur Java m'ont historiquement causé le plus de chagrin. Certains programmeurs Java ne programment pas correctement pour le nettoyage des ordures ou la libération de la mémoire, et des problèmes surviennent lorsque les charges sont élevées ou lorsque certains appels sont effectués. Je commence toujours par recommencer le processus. Ma prochaine option est de vérifier top pour la quantité de mémoire consommée par le programme. Si toutes mes vérifications et redémarrages de processus ne fonctionnent pas, je redémarre le système. Si le problème recommence, j'irai voir le programmeur, je me plaindrai et fournirai mes rapports.
Disque
Les disques échouent. C'est une affirmation forte mais vraie. Même les SSD échouent à un moment donné, alors préparez-vous à une panne de disque. N'oubliez pas que RAID n'est pas la même chose qu'une sauvegarde et que les disques et les partitions se remplissent, ce qui les fait se comporter avec des performances moins qu'optimales. Si vous pensez qu'un disque est votre tueur de performances, la première chose à regarder est l'espace disponible avec un rapide df commande :
$ df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 397M 0 397M 0% /dev
tmpfs 411M 0 411M 0% /dev/shm
tmpfs 411M 11M 400M 3% /run
tmpfs 411M 0 411M 0% /sys/fs/cgroup
/dev/sda2 16G 1.8G 14G 12% /
/dev/sda1 495M 152M 344M 31% /boot
tmpfs 83M 0 83M 0% /run/user/1000 Vous pouvez voir ci-dessus qu'il n'y a pas de systèmes de fichiers complets ou presque complets sur mon serveur.
L'élément suivant à vérifier est de savoir si vos systèmes de fichiers sont pleins ou presque pleins. Si ce n'est pas le cas, vous avez un disque défectueux. Je ne peux pas simuler une panne de disque, mais certains systèmes de serveur vous permettent de savoir quand ils ont des disques défaillants. Par exemple, certains de mes anciens serveurs affichaient une lumière orange plutôt qu'une lumière verte lorsque quelque chose n'allait pas. Faites attention à vos indicateurs matériels. J'avais aussi des serveurs qui avaient un petit écran LCD qui me notifiait les pannes et les erreurs. Ces outils m'ont été utiles lorsque le système d'exploitation ne m'a pas averti qu'il y avait un problème.
Un disque défaillant a un impact sur les performances, quelle que soit la configuration. Les configurations RAID ne garantissent pas les performances en cas de défaillance d'un disque membre. Au lieu de cela, ils garantissent la sécurité en raison de la redondance. En d'autres termes, vos données sont intactes, mais vos utilisateurs et clients seront mécontents en raison de la lenteur des performances. Attendez-vous à des problèmes de performances lorsqu'un disque membre tombe en panne.
Si votre système est lent, vérifiez le serveur physique et tous ses composants, alertes et messages. Cette étape est destinée à ceux qui ont accès à des serveurs physiques. Tant d'administrateurs système doivent gérer des systèmes distants ou hébergés et n'ont donc pas ce type d'accès.
Réseau
Les problèmes de réseau dus au matériel sont assez rares, mais ils se produisent. Une carte réseau bavarde, un mauvais câble ou un commutateur ou un port de commutateur défectueux peuvent être la source de beaucoup de frustration pour un administrateur système. Et, si vous ajoutez un port de commutateur ou une mauvaise configuration du réseau sur l'hôte lui-même, vous avez maintenant une recette pour beaucoup de cheveux tirés. Parfois, il est difficile de trouver la source d'un problème réseau car le problème peut être local, au niveau du commutateur ou quelque part au-delà du commutateur. Vous devez regarder chaque niveau séparément pour trouver le problème.
Vérifiez vos autres hôtes pour comparer. Le problème est-il localisé sur un seul hôte, est-il confiné à un seul groupe ou s'étend-il à l'ensemble du système ? Cette vérification vous aidera à déterminer si le problème est local, s'il est confiné à un seul commutateur, s'il affecte un rack ou une rangée entière, ou si le problème est plus répandu.
Vérifiez les configurations de votre réseau local. Vérifiez les journaux des modifications pour voir si quelque chose a récemment changé. Ensuite, effectuez une vérification physique de votre carte réseau. Est-ce que les feux vous semblent corrects ? Le câble est-il en bon état et la fiche semble-t-elle intacte ? La configuration des fils semble-t-elle correcte ? Vérifiez toute la longueur du câble pour des dommages physiques, si possible. Vérifiez si le commutateur physique et la terminaison de câble du commutateur présentent des défauts physiques.
Vérifiez vous-même la configuration du commutateur ou demandez à un administrateur réseau de le faire. Vérifiez physiquement l'emplacement du commutateur ou reportez-vous à votre documentation pour trouver le port correct à signaler à l'administrateur réseau. Si la configuration semble bonne, demandez à l'administrateur réseau d'effectuer une réinitialisation rapide sur le port. Demandez également à l'administrateur la dernière mise à jour du commutateur et la date du dernier redémarrage.
En fonction de votre travail et de l'endroit où vous travaillez, vous n'aurez peut-être pas le contrôle ou la visibilité au-delà de votre commutateur. Travaillez avec les administrateurs réseau, les FAI ou les fournisseurs d'hébergement pour localiser plus précisément un problème de performances réseau. L'expérience personnelle me dit qu'à moins qu'un problème de réseau ne soit généralisé, les administrateurs réseau veulent une preuve de ce que vous avez vérifié qui vous a conduit à blâmer le réseau. Pour cette raison, j'ai placé le dépannage du réseau en dernier dans la liste. Je ne compte plus le nombre de fois où j'ai entendu ces mots frustrants : "Ce n'est pas le réseau, mec. Ce doit être l'infrastructure." Et puis une tonalité.
Conclusion
Il n'y a pas de raccourcis pour acquérir des connaissances en matière de dépannage. Vous pouvez apprendre et vous préparer, mais malheureusement, l'expérience est le meilleur enseignant car vous devez faire l'expérience des échecs avant d'avoir une réelle idée du dépannage dans les tranchées. Même les échecs simulés ne vous donnent pas la même expérience qu'un échec réel, avec de vrais utilisateurs demandant quand les choses seront corrigées, et de vrais managers vous regardant comme si c'était de votre faute si l'entreprise perd de l'argent, et irrité que votre clavier ne le soit pas. ne fait aucun bruit.
Dépanner les problèmes n'est pas la partie amusante d'être un administrateur système, mais c'est une partie nécessaire. En fait, je ne sais pas s'il y a des parties amusantes, et elles sont toutes nécessaires. Être un administrateur système est stressant, et le dépannage des problèmes est une grande partie de ce stress. Je vous ai donné des conseils pour tenter de réduire ce stress, mais c'est toujours à vous d'acquérir de l'expérience et de la confiance pour les utiliser.