Cet article est extrait du chapitre 13 du livre Linux en action, publié par Manning.
Les performances de votre machine Linux ont-elles été irrégulières ou anormalement lentes ? Pensez-vous que la demande croissante pourrait dépasser vos ressources disponibles ? Voici quelques questions que vous devriez vous poser :
- Dans quelle mesure êtes-vous proche d'épuiser vos ressources de processeur et de mémoire ?
- Y a-t-il quelque chose qui fonctionne inutilement et qui pourrait être arrêté ?
- Y a-t-il quelque chose qui tourne mal à votre insu ?
Plus de ressources Linux
- Aide-mémoire des commandes Linux
- Aide-mémoire des commandes Linux avancées
- Cours en ligne gratuit :Présentation technique de RHEL
- Aide-mémoire sur le réseau Linux
- Aide-mémoire SELinux
- Aide-mémoire sur les commandes courantes de Linux
- Que sont les conteneurs Linux ?
- Nos derniers articles Linux
Où chercher des réponses ? Le haut programme est un excellent point de départ. Il peut vous donner un aperçu riche et auto-actualisé des processus en cours d'exécution sur votre système.
La figure ci-dessous montre un écran typique de top Les données. La première ligne indique l'heure actuelle, le temps écoulé depuis le dernier démarrage du système, le nombre d'utilisateurs actuellement connectés et les moyennes de charge pour la dernière minute, cinq minutes et 15 minutes. Ces informations peuvent également être renvoyées en exécutant uptime .
Puisque nous essayons de résoudre des problèmes de performances, les colonnes de données qui devraient nous intéresser le plus sont %CPU (pourcentage de la capacité CPU actuellement utilisée par un processus donné) et %MEM (pourcentage de la capacité mémoire). Vous voudrez particulièrement noter les processus apparaissant en haut de la liste.
Dans ce cas, vous pouvez voir que le démon MySQL utilise 4,3 % du processeur du serveur et, à partir de la colonne suivante, 13 % de sa mémoire. Si vous suivez cette ligne vers la gauche, vous verrez que l'ID de processus (PID) est 1367 et le processus est "possédé" par le mysql utilisateur.
Peut-être en conclurez-vous que ce processus prenait plus de ressources que ce qui peut être justifié et qu'il devra être sacrifié (pour le plus grand bien, vous comprenez). Ce top l'affichage vous a donné tout ce dont vous aurez besoin pour le tuer. Étant donné que MySQL est un service géré par systemd (sur les distributions utilisant systemd), votre premier choix devrait être d'utiliser systemctl pour ralentir le processus en douceur sans mettre en danger les données de l'application.
systemctl stop mysqld
Si le processus que vous souhaitez arrêter n'est pas géré par systemd, ou si quelque chose ne va pas et systemctl n'a pas réussi à l'arrêter, alors vous pouvez utiliser soit kill ou killall pour éliminer votre processus. Certains systèmes nécessitent que vous installiez killall dans le cadre du psmisc emballer. Vous passez le PID à kill de cette façon :
kill 1367
killall , en revanche, utilise le nom du processus plutôt que son ID.
killall mysqld
Tuer ou tout tuer, telle est la question . En fait, la réponse est assez évidente. kill arrêtera un seul processus, basé sur le PID, tandis que killall tuera autant d'instances d'un programme particulier qu'il est en cours d'exécution. Donc, s'il y avait deux ou trois instances MySQL distinctes, appartenant peut-être à des utilisateurs distincts, tout serait arrêté. Avant de lancer killall , assurez-vous qu'il n'y a pas de processus portant le même nom que vous souhaitez exécuter et qui pourraient devenir des "dommages collatéraux".
Bien sûr, vous devrez également exécuter systemctl disable pour vous assurer que le processus ne redémarre pas au prochain démarrage.
systemctl disable mysqld Décryptage haut
Au cas où vous en auriez besoin, la troisième ligne de top la sortie que vous avez vue un peu plus tôt nous donne des valeurs de temps (en pourcentage) pour un certain nombre d'autres métriques CPU. Voici un bref aperçu du méli-mélo d'acronymes que vous y trouverez :
| Métrique | Signification |
|---|---|
us | Temps d'exécution des processus de haute priorité (non-niced) |
sy | Temps d'exécution des processus du noyau |
ni | Temps d'exécution de processus de faible priorité (agréables) |
id | Temps passé au ralenti |
wa | Temps d'attente pour que les événements d'E/S se terminent |
hi | Temps passé à gérer les interruptions matérielles |
si | Temps passé à gérer les interruptions logicielles |
st | Temps volé à cette VM par son hyperviseur (hôte) |
Le top l'affichage peut être personnalisé en temps réel grâce à la saisie au clavier. Tapez h pour en savoir plus.
Créer des problèmes (simuler la charge du processeur)
Mourir d'envie de voir top en action mais, ne le sauriez-vous pas, tout se passe bien ?
Pourquoi ne pas simuler une surcharge CPU de niveau crise ? Tout comme les enfants, yes émettra du bruit (numérique) en continu jusqu'à ce qu'on lui dise d'arrêter. À la réflexion, ce n'est pas du tout comme les enfants.
Cette commande redirigera ce bruit vers le jetable /dev/null fichier et le & Le personnage poussera le processus en arrière-plan, vous redonnant le contrôle de la ligne de commande. Pour augmenter la pression, lancez la commande plusieurs fois.
$ yes > /dev/null &
Ça devrait les occuper. Pendant que tout cela tourne, regardez top pour voir ce qui se passe. Vous pouvez également essayer d'exécuter d'autres applications pour voir combien il faudra pour les ralentir. Lorsque vous avez terminé, exécutez killall pour faire tomber tous vos yes sessions en une seule fois.
$ killall yes