Système lent ? Comment voir si Linux est lié à la mémoire, au processeur ou aux E/S

0
204
Shutterstock/solarseven

Le système fonctionne lentement ? Si tel est le cas, votre système sera soit lié à la mémoire, soit au processeur, soit aux E/S. Cet article vous montrera un moyen rapide de savoir lequel des trois il s'agit, vous permettant d'améliorer les performances du système en toute connaissance de cause.

Mémoire, calcul ( CPU) ou I/O Bound ?

Chaque fois que votre système est lent, cela est presque toujours dû au composant ou à la chaîne de composants le plus lent de votre système. Cela peut parfois être causé par un logiciel, mais souvent, c'est le matériel qui est en cause.

Par exemple, si vous avez un disque très ancien et lent – par exemple, un disque tournant à 5 400 tr/min encore assez courant, souvent appelé disque dur ou disque dur – ce disque peut être le goulot d'étranglement de votre système.

Pensez-y comme des tuyaux avec de l'eau qui les traverse. Imaginez la mémoire de votre système, l'unité de calcul (votre CPU ou l'unité centrale de traitement &#8211 ; la puce/processeur principal de votre système) et les disques (dans le cadre du système d'E/S ou d'entrée/sortie) tout comme des conduites d'eau. Maintenant, imaginez que les composants les plus lents sont un tuyau plus petit et que les composants les plus rapides sont un tuyau plus gros. Si vous deviez transférer 10 L à travers chaque tuyau, le tuyau le plus lent prendra beaucoup plus de temps que le plus gros.

Sous Linux, les principaux goulots d'étranglement sont la mémoire (RAM), le calcul (CPU) ou les E/S (opérations sur disque). Dans le cas de la mémoire, la vitesse peut être un facteur, mais le manque de mémoire est un gros problème. Pour le processeur, si vous utilisez un matériel plus ancien, chaque cœur de processeur fonctionne beaucoup plus lentement et il se peut qu'il n'y en ait pas assez. Pour les E/S, la lecture à partir de disques durs lents ainsi que les écritures excessives sur le disque peuvent être le problème.

Publicité

Il existe des outils que vous pouvez utiliser pour savoir facilement si un système est en mémoire , Calcul (CPU) ou I/O Bound. Tout ce dont vous avez besoin est htop et iotop, deux outils semi-graphiques, qui peuvent être facilement installés sur Linux.

Installation de htop et iotop

Pour installer htop et iotop sur votre distribution Linux basée sur Debian/Apt (comme Ubuntu et Mint), procédez comme suit :

sudo apt install htop iotop

Pour installer htop et iotop sur votre RedHat/Distribution Linux basée sur Yum (comme RedHat et Fedora), faites :

sudo yum install htop iotop

CPU Bound

Il est facile de voir si un système est lié au processeur ou non. Tapez simplement `htop` sur la ligne de commande et appuyez sur Entrée. Regardez ensuite les barres colorées du processeur en haut de l'écran. Si votre processeur a 16 threads, il y aura 16 barres.

La simple question à laquelle il faut répondre est de savoir si elles sont toutes presque ‘pleines’ (près de 100 %), ou s'il y a suffisamment d'espace pour bouger :

Si les barres sont presque pleines, le système est clairement lié au processeur. Notez également que la mémoire (Mem) et les barres d'échange (Swp) ne sont en aucun cas pleines : ce n'est pas un problème de performances lié à la mémoire.

Pour un peu plus d'informations et de tendances, vous pouvez ensuite regarder la ‘Charge moyenne’ numéro. Bien que ce nombre soit hautement arbitraire, un peu de familiarité avec votre système et la compréhension générale que si l'un de ces trois nombres dépasse le double du nombre de threads de votre système, le système a du mal à suivre va très loin ici.< /p> Publicité

Le premier nombre moyen de charge est une moyenne de 1 minute, le suivant une moyenne de 5 minutes et le dernier nombre une moyenne de 15 minutes. Dans ce cas, la charge d'une minute est de 270, soit presque 17 fois le nombre de threads : notre système est fortement lié au processeur.

Enfin, un nombre intéressant à vérifier est le nombre de tâches (et dans une moindre mesure de threads). Bien que les limites exactes des limites inférieure et supérieure dépendent des capacités du matériel/machine sous-jacent, si le nombre de tâches est excessivement élevé, votre processeur peut basculer fortement dans le contexte (passant du traitement d'une tâche à une autre).

Si vous souhaitez en savoir plus sur ce qu'indiquent les différentes couleurs dans htop, consultez Barres de couleurs dans htop – Que signifient-ils ?

Mémoire liée

Immédiatement en accédant à htop, il est facile de voir si un système est lié à la mémoire ou ne pas. Il suffit de regarder les barres de mémoire (Mem) et d'échange (Swp) mentionnées précédemment.

Si la barre de mémoire est complètement pleine et que la barre d'échange est par exemple pleine à 50 %, le système effectue presque certainement des échanges importants. L'échange est le processus d'échange du contenu de la mémoire principale avec le disque (à l'aide d'un fichier d'échange spécial ou d'une partition d'échange) car il est plein, et il est généralement très lent. Une fois qu'un système démarre et continue d'échanger, il deviendra excessivement lent.

Il est facile de voir quand vous commencez à manquer de mémoire, car la barre deviendra pleine. Cependant, l'utilisation de l'espace d'échange peut parfois être un peu ambiguë.

Publicité

Par exemple, 20 % peuvent être utilisés, mais il reste beaucoup de mémoire. Cela peut indiquer que le système d'exploitation a déplacé certaines zones de mémoire d'utilisation à basse fréquence sur le disque afin d'optimiser la mémoire principale. Comme beaucoup de mémoire reste libre, cette situation est correcte et ne pose aucun problème.

Il existe également une exception à une barre de mémoire qui semble assez pleine, et qui est la mise en cache. Votre système peut être configuré pour réserver x quantité de mémoire pour la mise en cache.

Une autre façon de vérifier rapidement cela est d'exécuter free -g sur la ligne de commande (ou free -m pour les machines avec de plus petites quantités de mémoire comme un Raspberry Pi) :

C'est facile à lire : 62 Go de mémoire, 25 en cours d'utilisation, 12 libres et 24 actuellement affectés aux tampons et au cache. Les 32 disponibles sont un total approximatif de libres réels (12) et tout ce qui est affecté aux tampons et au cache (24) moins ce qui est déjà utilisé (non montré), ou en d'autres termes 12 + 24 = 36 et 32 ​​est disponible, donc environ 4 gigaoctets sont utilisés par les tampons et la mise en cache.

Notez que nous pouvons également voir combien d'espace de swap a été réservé (10 gigaoctets) et combien est utilisé ici : 0 actuellement, et donc 10 gratuit.

I/O lié

Disons que vous vérifiez htop et voyez ceci :

< img src="/wp-content/uploads/d45a9a96337f807a5c30105c55278d38.gif" />

Le système semble occupé, mais pas assezêtre considéré comme lié au processeur. La mémoire utilisée/libre et les barres d'échange ont également l'air bien. Passons à la caisse iotop ensuite. Pour ce faire, vous devez utiliser sudo iotop pour démarrer iotop car iotop nécessite sudo.

Publicité

Les deux barres du haut sont les plus utiles pour analyser rapidement si un système est aux prises avec le débit du disque et est donc lié aux E/S.

Alors que le M/s le nombre n'est pas très élevé en termes de SSD moderne, lire et écrire en permanence plusieurs mégaoctets par seconde sur un disque dur lent est assez intense en E/S !

Ce nombre, lorsqu'il est observé pendant un petit moment, ainsi que la liste de processus en dessous (pour voir qui sont les principaux utilisateurs) et la partie supérieure de la sortie htop (en termes de CPU et de mémoire) donne une bonne idée globale de si un le système est lié à la mémoire, au processeur ou aux E/S.

Atténuation des problèmes de performances

Les modifications du système requises pour atténuer les problèmes de performances sont toujours spécifiques au système ainsi que la situation spécifique vécue. Quelques exemples :

Le système est-il lié au Disque/E/S ? Il peut être judicieux d'arrêter certains services de journalisation d'écritures lourdes, de mettre à niveau le système d'E/S (par exemple en ajoutant une carte SATA dans un vieil ordinateur), de passer à un périphérique de stockage plus rapide (comme un disque basé sur NVMe au lieu d'un HDD), ou simplement pour trouver un SSD plus rapide.

Le système est-il lié à la Mémoire/Swap ? Il peut, par exemple, être judicieux d'exécuter moins de machines virtuelles, d'exécuter des processus moins gourmands en mémoire ou d'ajouter plus de modules de mémoire physique.

Publicité

Le système est-il lié ​​au processeur ? Utilisez la liste des processus du bas dans htop pour trouver le processus qui monopolise le processeur. Vous pouvez même y mettre fin directement depuis htop en utilisant la touche F9.

Si le problème est le processeur lui-même (c'est-à-dire que le processeur ne suit clairement pas les tâches les plus élémentaires associées au système), le changement de matériel est un peu plus complexe. Il faut trouver un processeur plus rapide, toujours compatible avec le socket de la carte mère, et même dans ce cas, les améliorations de performances peuvent être minimes. Il est peut-être temps de mettre à niveau le système dans son ensemble.

Plus d'un goulot d'étranglement des performances ?

Revenons à notre analogie avec les conduites d'eau, gardez à l'esprit que parfois un goulot d'étranglement peut être causé par une combinaison de divers composants.

Par exemple, si une carte contrôleur d'E/S ancienne ou bon marché nécessite 80% du temps CPU juste pour traiter les données, et le le disque qui y est attaché est un disque dur lent qui est utilisé à 80% de ses capacités, même avec le débit de la carte E/S moins chère, alors les deux créent un problème global qui ne sera pas résolu en abordant non plus. Les deux devront être corrigés avant que le système ne redevienne performant.

Résumé

Que vous soyez un ingénieur DevOps ou un utilisateur Linux d'ordinateur à domicile, sachant comment analyser rapidement si votre système est lié à la mémoire, au processeur ou aux E/S, vous aidera à mettre en œuvre de meilleures modifications logicielles et matérielles pour répondre aux problèmes de performances rencontrés.