Uso real de memoria de un proceso

Los siguientes son el uso de memoria de mysqly apacherespectivamente en mi servidor. Según la salida de pmapsay, mysqlestá usando aproximadamente 379M y apacheestá usando 277M.

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

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

Comparando esto con la salida de top, veo que los valores son casi coincidentes.

  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=....

Ahora estos valores definitivamente no son el uso de memoria actual de esos dos procesos, ya que si lo hubiera hecho, habría excedido los 512M ramen mi sistema y entiendo el hecho de que estos son el tamaño de las páginas asignadas a estos dos procesos y no realmente El tamaño de la memoria utilizada activamente por ellos. Ahora, cuando usamos pmap -x, veo un color adicional Dirtyque muestra mucho menos uso de memoria para el proceso. Como se ve en el ejemplo que se muestra a continuación, el Dirtycolor muestra 15 millones en comparación con 379 millones en el primer color. Mi pregunta es: ¿el valor bajo coloumn Dirtyes la cantidad 'real' de memoria utilizada activamente por ese proceso? Si no es así, ¿cómo podemos descubrir el uso real de la memoria de un proceso? No psy toppor las mismas razones anteriores. ¿Tenemos algo debajo/proc eso le dará esta información?

[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 ~]#

No hay ningún comando que proporcione el "uso de memoria real de un proceso" porque no existe el uso de memoria real de un proceso .

Cada página de memoria de un proceso podría ser (entre otras distinciones):

• Almacenamiento transitorio utilizado solo por ese proceso.
• Compartido con otros procesos utilizando una variedad de mecanismos.
• Respaldado por un archivo de disco.
• En memoria física o intercambio.

Creo que la cifra "sucia" suma todo lo que está en la RAM (no intercambio) y no está respaldado por un archivo. Esto incluye tanto la memoria compartida como la no compartida (aunque en la mayoría de los casos, aparte de bifurcar servidores, la memoria compartida consiste solo en archivos asignados a la memoria).

La información mostrada por pmapproviene de y . Ese es el uso real de la memoria del proceso: no se puede resumir en un solo número./proc/PID/maps/proc/PID/smaps

Citaré algo que escribí en la página de manual para una aplicación que hace un análisis similar a la parte superior y extrae información de las mismas fuentes que pmap(por ejemplo /proc/[N]/maps):

ESPACIO DE DIRECCIÓN VIRTUAL VS. MEMORIA FÍSICA

Es importante comprender la diferencia entre el espacio de direcciones virtuales y la memoria física al interpretar algunas de las estadísticas anteriores. Como su nombre lo indica, el espacio de direcciones virtuales no es real; Básicamente es un mapa de toda la memoria asignada actualmente a un proceso. El límite en el tamaño de este mapa es el mismo para cada proceso (generalmente, 2-4 GB), y no se acumula (es decir, puede tener docenas o cientos de procesos, cada uno con su propia dirección virtual de 2-4 GB espacio, en un sistema que solo tiene 512 MB de memoria física ).

Los datos no pueden almacenarse o recuperarse realmente del espacio de direcciones virtuales; Los datos reales requieren memoria física real. El trabajo del núcleo es administrar uno en relación con otro. Las estadísticas de espacio virtual (VirtualSz, Data + Stack y Priv & Write) son útiles para considerar la estructura de un proceso y la relación con el uso de la memoria física, pero con respecto a la cantidad de RAM realmente utilizada, las estadísticas de la memoria física (ResidentSz, Share y Proporción) son lo que cuenta.

pmapprincipalmente le informa información sobre el espacio de direcciones virtuales . Su observación de que "los valores son casi coincidentes" en la topsalida presumiblemente se refiere a la figura VIRT, que es muy diferente a la figura RES. Estos corresponden exactamente a lo que he marcado "VirtualSz" y "ResidentSz" (el VIRT es para virtual, el RES es para residente).

Ahora, cuando usamos pmap -x, veo un color extra sucio que muestra mucho menos uso de memoria para el proceso. Como se ve en el ejemplo que se muestra a continuación, el color sucio muestra 15 millones en lugar de 379 millones en el primer color. Mi pregunta es: ¿el valor bajo Coloumn Dirty es la cantidad 'real' de memoria utilizada activamente por ese proceso?

No, pero más o menos. La memoria "sucia" se refiere a los datos que se han cargado desde el disco y posteriormente modificados; Como se ha modificado, debe formar parte de la memoria residente porque estos cambios se almacenan actualmente en la RAM. Sin embargo, no es sinónimo de ello.

La memoria virtual es como los números de marcación rápida, excepto que hay alrededor de 3 mil millones o ellos (para el sistema de 32 bits, 4 mil millones para la aplicación de 32 bits en el núcleo de 64 bits, mucho más para la aplicación de 64 bits), y no puede marcar números directamente, tienen para ser mapeado a marcación rápida.

Varios procesos pueden tener asignaciones diferentes (números de marcación rápida) para la misma dirección (números de teléfono). Por ejemplo, pueden compartir varias bibliotecas, así que tenga direcciones virtuales para toda la biblioteca (puede ver eso en pmap). Incluso pueden compartir el mismo ejecutable, por ejemplo, 2 instancias de bash.

Hasta ahora, esto explica cómo puede encajar el sub de todas las direcciones virtuales, pero hay más. Un proceso puede tener tanta memoria virtual que no debería caber, ¿cómo? Es posible que algunas partes de una biblioteca o archivos ejecutables no se usen, no se copiarán del disco a la memoria RAM, o la memoria RAM se llena y los bits que se cargaron desde el disco se caen, porque pueden volver a buscarse desde el disco si es necesario, o la memoria que no está respaldada, mi disco se asigna para intercambiar, se copia para intercambiar y luego se cae. Luego se puede leer desde el intercambio si es necesario. Si alguna de estas últimas estrategias se usa demasiado, el sistema se vuelve lento.