Utilisation réelle de la mémoire d'un processus

Voici l'utilisation de la mémoire de mysqlet apacherespectivement sur mon serveur. Selon la sortie de pmapdisons, mysqlutilise environ 379M et apacheutilise 277M.

[root@server ~]# pmap 10436 | grep total
 total           379564K

[root@server ~]# pmap 10515 | grep total
 total           277588K

En comparant cela avec la sortie de top, je vois que les valeurs correspondent presque.

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
10515 apache    20   0  271m  32m 3132 S  0.0  6.6   0:00.73 /usr/sbin/httpd
10436 mysql     20   0  370m  21m 6188 S  0.0  4.3   0:06.07 /usr/libexec/mysqld --basedir=....

Maintenant, ces valeurs ne sont certainement pas l'utilisation actuelle de la mémoire de ces deux processus, car si elle avait dépassé les 512 Mo ramsur mon système et je comprends le fait que ce sont la taille des pages affectées à ces deux processus et pas vraiment la taille de la mémoire qu'ils utilisent activement. Maintenant, lorsque nous utilisons pmap -x, je vois une colonne supplémentaire Dirtyqui montre beaucoup moins d'utilisation de la mémoire pour le processus. Comme le montre l'exemple ci-dessous, la Dirtycolonne affiche 15 M au lieu de 379 M dans la première colonne. Ma question est: la valeur sous coloumn Dirtyest-elle la «vraie» quantité de mémoire activement utilisée par ce processus? Si ce n'est pas le cas, comment pouvons-nous découvrir l'utilisation réelle de la mémoire d'un processus? Non pset toppour les mêmes raisons que ci-dessus. Avons-nous quelque chose sous/proc qui donnera cette info?

[root@server ~]# pmap -x 10436 | grep total
total kB          379564   21528   15340
[root@server ~]#


[root@server ~]# free -m
             total       used       free     shared    buffers     cached
Mem:           489        447         41          0         52        214
-/+ buffers/cache:        180        308
Swap:         1023          0       1023
[root@server ~]#

Il n'y a aucune commande qui donne «l'utilisation réelle de la mémoire d'un processus» car il n'y a rien de tel que l'utilisation réelle de la mémoire d'un processus .

Chaque page mémoire d'un processus peut être (entre autres distinctions):

• Stockage transitoire utilisé uniquement par ce processus.
• Partagé avec d'autres processus en utilisant une variété de mécanismes.
• Sauvegardé par un fichier disque.
• Dans la mémoire physique ou l'échange.

Je pense que le chiffre «sale» additionne tout ce qui est en RAM (pas swap) et non sauvegardé par un fichier. Cela inclut à la fois la mémoire partagée et non partagée (bien que dans la plupart des cas, à l'exception des serveurs bifurcateurs, la mémoire partagée se compose uniquement de fichiers mappés en mémoire).

Les informations affichées par pmapproviennent de et . C'est l'utilisation réelle de la mémoire du processus - elle ne peut pas être résumée par un seul numéro./proc/PID/maps/proc/PID/smaps

Je citerai quelque chose que j'ai écrit dans la page de manuel pour une application qui fait une analyse similaire à top et qui tire des informations des mêmes sources que pmap(par exemple /proc/[N]/maps):

ESPACE D'ADRESSE VIRTUELLE VS. MÉMOIRE PHYSIQUE

Il est important de comprendre la différence entre l' espace d'adressage virtuel et la mémoire physique lors de l'interprétation de certaines des statistiques ci-dessus. Comme son nom l'indique, l'espace d'adressage virtuel n'est pas réel; il s'agit essentiellement d'une carte de toute la mémoire actuellement allouée à un processus. La limite de taille de cette carte est la même pour chaque processus (généralement, 2 à 4 Go), et elle n'est pas cumulée (c'est-à-dire que vous pouvez avoir des dizaines ou des centaines de processus, chacun avec sa propre adresse virtuelle de 2 à 4 Go. sur un système qui ne dispose en fait que de 512 Mo de mémoire physique ).

Les données ne peuvent pas réellement être stockées ou récupérées à partir de l'espace d'adressage virtuel; les données réelles nécessitent une mémoire physique réelle. C'est le travail du noyau de gérer l'un par rapport à l'autre. Les statistiques de l'espace virtuel (VirtualSz, Data + Stack et Priv & Write) sont utiles pour considérer la structure d'un processus et la relation avec l'utilisation de la mémoire physique, mais en ce qui concerne la quantité de RAM réellement utilisée, les statistiques de la mémoire physique (ResidentSz, Share et La proportion) est ce qui compte.

pmapvous fournit principalement des informations sur l' espace d'adressage virtuel . Votre observation selon laquelle "les valeurs correspondent presque" dans la topsortie fait probablement référence au chiffre VIRT, qui est très différent du chiffre RES. Ceux-ci correspondent exactement à ce que j'ai appelé ci-dessus "VirtualSz" et "ResidentSz" (le VIRT est pour le virtuel, le RES est pour le résident).

Maintenant, lorsque nous utilisons pmap -x, je vois un coloumn supplémentaire sale qui montre beaucoup moins d'utilisation de la mémoire pour le processus. Comme le montre l'exemple ci-dessous, la colonne sale montre 15M contre 379M dans la première colonne. Ma question est la suivante: la valeur sous coloumn Dirty est-elle la «vraie» quantité de mémoire activement utilisée par ce processus?

Non, mais en quelque sorte. La mémoire «sale» fait référence aux données qui ont été chargées à partir du disque et modifiées par la suite; car il a été modifié, il doit faire partie de la mémoire résidente car ces modifications sont actuellement stockées dans la RAM. Cependant, il n'en est pas synonyme.

La mémoire virtuelle est comme des numéros abrégés, sauf qu'il y en a environ 3 milliards (pour un système 32 bits, 4 milliards pour une application 32 bits sur un noyau 64 bits, beaucoup plus pour une application 64 bits), et vous ne pouvez pas composer de numéros directement, ils ont à mapper à la numérotation rapide.

Plusieurs processus peuvent avoir des mappages différents (numéros abrégés) pour la même adresse (numéros de téléphone). Par exemple, ils peuvent partager plusieurs bibliothèques, ont donc des adresses virtuelles pour toute la bibliothèque (vous pouvez le voir dans pmap). Ils peuvent même partager le même exécutable, par exemple 2 instances de bash.

Jusqu'à présent, cela explique comment le sous-ensemble de l'adresse virtuelle peut s'adapter, mais il y a plus. Un processus peut avoir tellement de mémoire virtuelle qu'il ne devrait pas tenir, comment? Certaines parties d'une bibliothèque ou exécutable peuvent ne pas être utilisées, elles ne seront pas copiées du disque vers le ram, ou le ram est plein et les bits qui étaient chargés à partir du disque sont supprimés, car ils peuvent être récupérés du disque si nécessaire, ou de la mémoire non sauvegardée, mon disque est mappé pour être échangé, copié pour être échangé, puis supprimé. Il peut ensuite être lu à partir de swap si et quand cela est nécessaire. Si l'une de ces dernières stratégies est trop utilisée, le système devient lent.