Si vous faites du travail d'administrateur système depuis assez longtemps, vous avez vu les redoutables incidents "Le serveur est lent". Pendant longtemps, ces types d'incidents me donnaient un trou dans l'estomac. Comment diable résolvez-vous quelque chose d'aussi subjectif ? Le « lent » d'un utilisateur ordinaire peut simplement être causé par d'autres processus (planifiés ou non) qui s'exécutent et consomment plus de ressources que d'habitude, ou quelque chose peut réellement ne pas fonctionner avec le serveur.
Lorsque j'ai commencé à travailler en tant qu'administrateur système, je répondais immédiatement :"J'ai besoin de plus d'informations à ce sujet." Eh bien, généralement, l'utilisateur n'est pas en mesure de donner plus d'informations, car il ne sait pas ce qui se passe dans les coulisses ou comment expliquer ce qu'il voit autrement que "c'est juste lent". Aujourd'hui, avant même de répondre à l'utilisateur, je vérifie quelques éléments.
Connexion initiale
Il y a beaucoup de choses que vous pouvez dire en vous connectant à l'hôte. Pouvez-vous vous connecter du tout? La connexion est-elle lente ou bloquée ? Le ssh La commande a trois niveaux de débogage, chacun d'eux vous donnant une pléthore d'informations avant même d'être sur le système. Pour activer le débogage, ajoutez simplement un v supplémentaire au -v option. Par exemple, un débogage de niveau trois, que j'utilise exclusivement, serait :
[~]$ ssh -vvv hostname.domain.com
Les "Big 3" (alias CPU, RAM et Disk I/O)
Examinons maintenant les trois principales causes de ralentissement du serveur :le processeur, la RAM et les E/S de disque. L'utilisation du processeur peut entraîner une lenteur globale de l'hôte et des difficultés à effectuer les tâches en temps opportun. Certains outils que j'utilise lorsque je regarde le CPU sont top etsar .
Vérification de l'utilisation du CPU avec top
Le top vous donne un aperçu en temps réel de ce qui se passe avec le serveur. Par défaut, lorsque top démarre, il affiche l'activité de tous les processeurs :
Cette vue peut être modifiée en appuyant sur la touche numérique 1, ce qui ajoute plus de détails concernant les valeurs d'utilisation pour chaque CPU :
Certaines choses à rechercher dans cette vue seraient la charge moyenne (affichée sur le côté droit de la ligne supérieure) et la valeur des éléments suivants pour chaque CPU :
us:Ce pourcentage représente la quantité de CPU consommée par les processus utilisateur.sy:Ce pourcentage représente la quantité de CPU consommée par les processus système.id:Ce pourcentage représente le degré d'inactivité de chaque processeur.
Chacune de ces trois valeurs peut vous donner une assez bonne idée en temps réel de la liaison des processeurs par les processus utilisateur ou les processus système.
Pour vraiment expliquer la charge moyenne, il faudrait un article à lui tout seul. Pour les besoins de cet article, je vais parler de généralités. Les trois valeurs moyennes de charge de gauche à droite représentent des moyennes sur une minute, cinq minutes et 15 minutes. Encore une fois, parlant très généralement, si vous constatez que la moyenne sur une minute dépasse le nombre de processeurs physiques dont vous disposez, le système est très probablement lié au processeur.
Remarque : Pour plus d'informations sur la charge moyenne et pourquoi certaines personnes pensent que c'est un chiffre idiot, consultez les recherches approfondies de Brendan Gregg.
Vérification de tous les "Big 3" avec sar
Pour les données historiques de performances du processeur, je m'appuie sur le sar commande, qui est fournie par le sysstat emballer. Sur la plupart des versions serveur de Linux, sysstat est installé par défaut, mais si ce n'est pas le cas, vous pouvez l'ajouter avec le gestionnaire de paquets de votre distribution. Le sar l'utilitaire collecte les données système toutes les 10 minutes via une tâche cron située dans /etc/cron.d/sysstat (CentOS 7.6). Voici comment vérifier tous les "Big 3" à l'aide de sar .
Remarque : Si vous venez d'installer sar pour suivre cet article, donnez d'abord à la commande le temps d'enregistrer les données.
La commande sar -u vous donne des informations sur tous les processeurs du système, à partir de minuit :
Comme avec top , les principales choses à vérifier ici sont %user , %system , %iowait , et %idle . Ces informations peuvent vous indiquer depuis combien de temps le serveur rencontre des problèmes.
Dans l'ensemble, le sar La commande peut fournir beaucoup d'informations. Étant donné que cet article explique juste une vérification rapide de ce qui se passe sur le serveur, consultez man sar pour détailler encore plus ces informations.
Pour vérifier les performances de la RAM, j'utilise sar -r , qui vous donne l'utilisation de la mémoire ce jour :
La principale chose à rechercher dans l'utilisation de la RAM est %memused et %commit . Un mot rapide sur le %commit champ :ce champ peut afficher plus de 100 % puisque le noyau Linux surcharge régulièrement la RAM. Si %commit est constamment supérieur à 100 %, ce résultat pourrait être un indicateur que le système a besoin de plus de RAM.
Pour les performances d'E/S disque, j'utilise sar -d , qui vous donne la sortie d'E/S du disque en utilisant uniquement le nom du périphérique. Pour obtenir le nom des appareils, utilisez sar -dP :
Pour cette sortie, en regardant %util et %await vous donnera une bonne image globale des E/S de disque sur le système. Le %util est assez explicite :c'est l'utilisation de cet appareil. Le await Le champ contient le temps que l'E/S passe dans le planificateur. L'attente est mesurée en millisecondes, et dans mon environnement, j'ai vu que tout ce qui dépasse 50 ms commence à causer des problèmes. Ce seuil peut varier dans votre environnement.
Si l'une de ces commandes montre un problème, vous pouvez revenir en arrière pour voir quand les problèmes de serveur ont commencé en utilisant sar {-u, -r, -d, -dP} -f /var/log/sa/sa<XX> (où XX est le jour du mois que vous souhaitez rechercher).
À ce stade, j'ai généralement une bonne idée de ce qui se passe actuellement sur le serveur et de ce qui s'est passé au cours des dernières 48 heures environ. Je répondrai à l'utilisateur avec des réponses plus éclairées. Par exemple :"Je ne vois aucune indication de lenteur de l'hôte au cours des dernières 24 heures. Veuillez essayer d'utiliser un nouveau profil putty pour ssh et faites-moi savoir si vous continuez à avoir des problèmes."
Un autre exemple :"Je ne vois rien qui cause actuellement des problèmes sur cet hôte, mais j'ai remarqué une charge CPU plus élevée $time . C'est à ce moment-là que vous avez vu des problèmes ? Si c'est le cas, essayez maintenant et faites-moi savoir si vous continuez à rencontrer des problèmes."
Vous avez eu l'idée. Avoir les informations fournies en regardant la connexion initiale puis en exécutant quelques sar commandes, qui me prennent généralement moins de 10 minutes à exécuter, font beaucoup pour éviter plus de questions et parvenir à une résolution plus rapidement.