60 votes

Comment comprendre l'utilisation de la mémoire et la charge moyenne d'un serveur linux ?

J'utilise un serveur linux doté de 128 Go de mémoire et de 24 cœurs. J'utilise top pour voir combien il est utilisé. Sa sortie est collée à la fin de ce post. Voici deux questions :

(1) Je vois que chacun des processus en cours d'exécution occupe un très petit pourcentage de mémoire (%MEM pas plus de 0,2%, et la plupart juste 0,0%), mais comment la mémoire totale est presque utilisée comme dans la quatrième ligne de sortie ("Mem : 130766620k total, 130161072k used, 605548k free, 919300k buffers") ? La somme des pourcentages de mémoire utilisée par tous les processus semble peu susceptible d'atteindre presque 100%, n'est-ce pas ?

(2) comment comprendre la moyenne de charge sur la première ligne ("moyenne de charge : 14.04, 14.02, 14.00") ?

Merci et salutations !

Edit :

Gracias.

J'aimerais aussi entendre des chiffres approximatifs basés sur le pourcentage de mémoire utilisé pour déterminer si un serveur est fortement chargé, car je suis devenu une fois celui qui a cramé le serveur sans comprendre la charge actuelle.

Le swap est-il considéré comme presque identique à la mémoire ? Par exemple, lorsque la mémoire et l'espace de pagination ont presque la même taille, si la mémoire est presque épuisée mais que l'espace de pagination est encore largement libre, puis-je considérer que le pourcentage de mémoire + espace de pagination utilisé n'est pas encore élevé et lancer d'autres processus ?

Comment considérez-vous l'utilisation conjointe du CPU ou de la mémoire (ou de la mémoire + swap) ? Vous inquiétez-vous si l'un des deux atteint un niveau trop élevé ou les deux ?

Sortie du sommet

Haut de page

top - 12:45:33 up 19 days, 23:11, 18 users,  load average: 14.04, 14.02, 14.00
Tasks: 484 total,  12 running, 472 sleeping,   0 stopped,   0 zombie
Cpu(s): 36.7%us, 19.7%sy,  0.0%ni, 43.6%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  130766620k total, 130161072k used,   605548k free,   919300k buffers
Swap: 63111312k total,   500556k used, 62610756k free, 124437752k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 6529 sanchez   18  -2 1075m 219m  13m S  100  0.2  13760:23 MATLAB
13210 timothy   18  -2 48336  37m 1216 R  100  0.0   3:56.75 absurdity
13888 timothy   18  -2 48336  37m 1204 R  100  0.0   2:04.89 absurdity
14542 timothy   18  -2 48336  37m 1196 R  100  0.0   1:08.34 absurdity
14544 timothy   18  -2  2888 2076  400 R  100  0.0   1:06.14 gatherData
 6183 sanchez   18  -2 1133m 195m  13m S  100  0.2  13676:04 MATLAB
 6795 sanchez   18  -2 1079m 210m  13m S  100  0.2  13734:26 MATLAB
10178 timothy   18  -2 48336  37m 1204 R  100  0.0  11:33.93 absurdity 
12438 timothy   18  -2 48336  37m 1216 R  100  0.0   5:38.17 absurdity
13661 timothy   18  -2 48336  37m 1216 R  100  0.0   2:44.13 absurdity
14098 timothy   18  -2 48336  37m 1204 R  100  0.0   1:58.31 absurdity
14335 timothy   18  -2 48336  37m 1196 R  100  0.0   1:08.93 absurdity
14765 timothy   18  -2 48336  37m 1196 R   99  0.0   0:32.57 absurdity
13445 timothy   18  -2 48336  37m 1216 R   99  0.0   3:01.37 absurdity
28990 root      20   0     0    0    0 S    2  0.0  65:50.21 pdflush
12141 tim       18  -2 19380 1660 1024 R    1  0.0   0:04.04 top
 1240 root      15  -5     0    0    0 S    0  0.0  16:07.11 kjournald
 9019 root      20   0  296m 4460 2616 S    0  0.0  82:19.51 kdm\_greet
    1 root      20   0  4028  728  592 S    0  0.0   0:03.11 init
    2 root      15  -5     0    0    0 S    0  0.0   0:00.00 kthreadd
    3 root      RT  -5     0    0    0 S    0  0.0   0:01.01 migration/0
    4 root      15  -5     0    0    0 S    0  0.0   0:08.13 ksoftirqd/0
    5 root      RT  -5     0    0    0 S    0  0.0   0:00.00 watchdog/0
    6 root      RT  -5     0    0    0 S    0  0.0  17:27.31 migration/1
    7 root      15  -5     0    0    0 S    0  0.0   0:01.21 ksoftirqd/1
    8 root      RT  -5     0    0    0 S    0  0.0   0:00.00 watchdog/1
    9 root      RT  -5     0    0    0 S    0  0.0  10:02.56 migration/2
   10 root      15  -5     0    0    0 S    0  0.0   0:00.34 ksoftirqd/2
   11 root      RT  -5     0    0    0 S    0  0.0   0:00.00 watchdog/2
   12 root      RT  -5     0    0    0 S    0  0.0   4:29.53 migration/3
   13 root      15  -5     0    0    0 S    0  0.0   0:00.34 ksoftirqd/3

56voto

Pascal Thivent Points 1485

(1) Je vois que chacun des processus en cours d'exécution occupe un très petit pourcentage de mémoire (%MEM pas plus de 0,2%, et la plupart juste 0,0%), mais comment la mémoire totale est presque utilisée comme dans la quatrième ligne de sortie ("Mem : 130766620k total, 130161072k used, 605548k free, 919300k buffers") ? La somme des pourcentages de mémoire utilisée par tous les processus semble peu susceptible d'atteindre presque 100%, n'est-ce pas ?

Pour voir combien de mémoire vous utilisez actuellement, exécutez free -m . Il fournira des résultats comme :

             total       used       free     shared    buffers     cached
Mem:          2012       1923         88          0         91        515
-/+ buffers/cache:       1316        695
Swap:         3153        256       2896

La valeur "usagée" de la première ligne (1923) correspondra presque toujours à la valeur "mém" de la première ligne (2012). Puisque Linux aime utiliser toute la mémoire disponible pour mettre en cache les blocs de disque (515).

Le chiffre clé utilisé à examiner est la valeur des tampons/rangées de cache utilisés (1316). Il s'agit de l'espace que vos applications utilisent actuellement. Pour des performances optimales, ce chiffre doit être inférieur à votre mémoire totale (2012). Pour éviter les erreurs de mémoire, il doit être inférieur à la mémoire totale (2012) et à l'espace d'échange (3153).

Si vous souhaitez voir rapidement combien de mémoire est libre, regardez la valeur libre des tampons/rangées de cache (695). Il s'agit de la mémoire totale (2012) - la mémoire réelle utilisée (1316). (2012 - 1316 = 696, pas 695, c'est juste un problème d'arrondi).

(2) comment comprendre la moyenne de charge sur la première ligne ("moyenne de charge : 14.04, 14.02, 14.00") ?

Cet article sur la moyenne de charge utilise une belle analogie avec le trafic et est la meilleure que j'ai trouvée jusqu'à présent : Comprendre la charge CPU de Linux - quand faut-il s'inquiéter ? . Dans votre cas, comme les gens l'ont souligné :

Sur un système multiprocesseur, la charge est relative au nombre de cœurs de processeur disponibles. La marque "100% d'utilisation" est de 1,00 sur un système à un seul cœur, 2,00, sur un double cœur, 4,00 sur un quadruple cœur, etc.

Ainsi, avec une charge moyenne de 14,00 et 24 cœurs, votre serveur est loin d'être surchargé.

17voto

Hurda Points 614

Les systèmes de type Unix, y compris linux, sont conçus pour utiliser le plus efficacement possible la mémoire vive disponible. En termes très généraux, il existe 3 états dans lesquels chaque Mo de RAM peut se trouver :

  1. Gratuit
  2. Utilisé par un processus
  3. Utilisé pour les tampons

Le troisième état est uniquement utilisé comme espace de grattage et est destiné à être réaffecté chaque fois que nécessaire, c'est-à-dire que votre mémoire totale disponible pour les programmes est en réalité Free+UsedforBuffers. En tant que tel, vous ne verrez pas vraiment l'espace alloué aux tampons apparaître comme attribué à un processus spécifique.

Votre question sur la moyenne de charge est un peu plus intéressante, car elle peut facilement être mal interprétée. Pour l'histoire complète, voir ceci article de linuxjournal . Le meilleur résumé est une citation directe de l'article,

Le calcul de la moyenne de charge peut être considéré comme une moyenne mobile des processus dans la file d'attente de Linux marqués comme étant en cours d'exécution ou ininterrompus.

En d'autres termes, vous pouvez considérer que votre charge moyenne est égale à (nombre de processus en cours d'exécution)+(nombre de processus en attente d'E/S). En gardant à l'esprit qu'à tout moment vous pouvez avoir $CORE nombre de processus en cours d'exécution, je dirais que votre moyenne de charge de 14 est assez faible.

4voto

jason saldo Points 5036

De la sar page de manuel :

       The load  average is  calculated as  the average number  of runnable or 
       running  tasks (R state), and the  number  of tasks in  uninterruptible
       sleep (D state) over the specified interval.

De la uptime page de manuel :

       System load averages is the average number of processes that are either
       in a runnable or uninterruptable state.  A process in a runnable  state
       is  either  using the CPU or waiting to use the CPU. A process in unin
       terruptable state is waiting for some I/O access, eg waiting for  disk.
       The  averages  are  taken over the three time intervals.  Load averages
       are not normalized for the number of CPUs in a system, so a load  aver
       age  of 1 means a single CPU system is loaded all the time while on a 4
       CPU system it means it was idle 75% of the time.

3voto

Corin Blaikie Points 6223
  1. Linux, depuis quelques temps maintenant, gère sa mémoire d'une manière qui rend cette ligne de top fondamentalement inutile, gardant généralement la plupart de la mémoire de la machine allouée pour des utilisations diverses lorsqu'elle n'est pas requise par un processus utilisateur.
  2. La moyenne de charge est le nombre moyen de processus en cours d'exécution ou en attente d'exécution. Elle a généralement une forte corrélation négative avec la latence/réactivité du système, donc vous la voulez aussi basse que possible. Comme chacun de vos processeurs peut exécuter quelque chose à tout moment, vous semblez vous en sortir plutôt bien avec 14.

0voto

dmityugov Points 756

La moyenne de charge est une bonne chose. Elle vous permet de comprendre ce qui se passe au-delà d'une utilisation de 100 %, en fait : http://en.wikipedia.org/wiki/Load_%28computing%29

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X