Utilisation réelle de la mémoire d'un processus
Voici l'utilisation de la mémoire de mysql et Apache respectivement sur mon serveur. Selon la sortie de pmap disons, mysql utilise environ 379M et Apache utilise 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 l'avait été, elle aurait dépassé les 512 Mo ram sur mon système et je comprends que ce sont la taille des pages affectées à ces deux processus et pas vraiment la taille de la mémoire activement utilisée par eux. Maintenant, lorsque nous utilisons pmap -x, Je vois une colonne supplémentaire Dirty qui montre beaucoup moins d'utilisation de la mémoire pour le processus. Comme le montre l'exemple ci-dessous, la colonne Dirty affiche 15M contre 379M dans la première colonne. Ma question est: la valeur sous coloumn Dirty est-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? Pas ps et top pour 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 pas de 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 autre que bifurquer les serveurs, la mémoire partagée se compose uniquement de fichiers mappés en mémoire).
Les informations affichées par pmap proviennent de /proc/PID/maps et /proc/PID/smaps. 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.
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 à partir 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 dans 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 la 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.-à-d. vous pouvez avoir des dizaines ou des centaines de processus, chacun avec son propre 2- 4 Go d'espace d'adressage virtuel, sur un système qui n'a en fait que 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é, le les statistiques de la mémoire physique (ResidentSz, Share et Proportion) sont ce qui compte.
pmap vous informe principalement sur espace d'adressage virtuel . Votre observation selon laquelle "les valeurs correspondent presque" dans la sortie top fait vraisemblablement référence à la figure VIRT, qui est très différente de la figure RES. Celles-ci correspondent exactement à ce que j'ai appelé ci-dessus "VirtualSz" et "ResidentSz" (le VIRT est pour le virtuel, le RES 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 affiche 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; puisqu'il a été modifié, il doit faire partie de mémoire résidente car ces changements sont actuellement stockés 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.