Análisis de memoria de Linux con comandos gratuitos y Pmap

Cuando hablamos de memoria, entonces son los parámetros más incomprendidos de todo el sistema, especialmente, cuando hablamos de Unix como sistema.

Este artículo habla principalmente de herramientas simples que se pueden utilizar para evaluar la utilización de la memoria por un proceso o un sistema en su conjunto.

Dos áreas principales son la memoria del núcleo y la memoria del usuario, ahora ampliemos un poco estos términos.

Memoria del kernel

Es la memoria administrada por el kernel que se compone de:

• Texto: donde solo se almacenan las partes de solo lectura del programa. Este suele ser el código de instrucción real del programa. Varias instancias del mismo programa pueden compartir esta área de memoria.

• Datos estáticos: el área donde se asigna la memoria preconocida. Esto es generalmente para variables globales y miembros de la clase C ++ estática. El sistema operativo asigna una copia de esta área de memoria para cada instancia del programa.

• Memory Arena (también conocido como espacio de descanso): el área donde se almacena la memoria dinámica en tiempo de ejecución. La arena de la memoria consiste en el montón y la memoria no utilizada. El montón es donde se encuentra toda la memoria asignada por el usuario. El montón crece desde una dirección de memoria más baja a una dirección de memoria más alta.

• Pila: siempre que un programa realiza una llamada a una función, el estado de la función actual debe guardarse en la pila. La pila crece desde una dirección de memoria más alta a una dirección de memoria más baja. Existe una arena y una pila de memoria únicas para cada instancia del programa.

Memoria de usuario

Reside en el montón de memoria y es llamado por rutinas de memoria como malloc (), realloc, free (), callo ()
Por lo tanto, la memoria juega un papel importante en el rendimiento del sistema y es uno de los componentes más críticos a analizar durante un problema de rendimiento del sistema, tenemos muchas herramientas a través de las cuales se puede medir el rendimiento del sistema, pero a veces fallan miserablemente, especialmente cuando usted está no verificando un laboratorio de cosecha propia, sino una caja de producción en funcionamiento crítico con 60G de RAM, CPU de múltiples núcleos y aplicaciones pesadas que generan millones de conexiones y, por lo tanto, crean un cuello de botella en el rendimiento, en tales escenarios, ejecutar un comando superior definitivamente no reflejará el uso real de la memoria y así, en tales escenarios, generalmente no confiamos mucho en los comandos ps o top, ya que informan el uso de la memoria del proceso en el concepto de que es el único proceso que se ejecuta en el sistema operativo, pero en realidad Linux también tiene algunos conceptos de bibliotecas compartidas, Entonces, cuando hacemos un ps o top en un proceso para obtener el uso, ignora otras cosas relacionadas con la memoria, como las secciones compartidas / privadas que muestran el uso real de la memoria, esta línea a continuación ayudará nosotros encontramos el material exacto para ejecutar procesos.

No deberías estar feliz siempre con estos primeros trazos:

[redhat@localhost Desktop]$ ps -e -o user,pid,%cpu,%mem,rss,cmd --sort=-rss | head
USER PID %CPU %MEM RSS CMD
redhat 3114 4.2 1.1 21612 /usr/lib/vmware-tools/sbin32/vmtoolsd -n vmusr
root 2673 5.9 1.0 20032 /usr/bin/Xorg :0 -nr -verbose -audit 4 -auth /var/run/gdm/auth-for-gdm-WW9iey/database -nolisten tcp vt1
redhat 3090 5.3 0.9 18928 nautilus
redhat 3161 1.3 0.8 17444 /usr/bin/gnote --panel-applet --oaf-activate-iid=OAFIID:GnoteApplet_Factory --oaf-ior-fd=19
redhat 3207 3.4 0.7 14384 /usr/bin/gnome-terminal -x /bin/sh -c cd '/home/redhat/Desktop' && exec $SHELL
redhat 3162 1.2 0.6 13084 /usr/libexec/clock-applet --oaf-activate-iid=OAFIID:GNOME_ClockApplet_Factory --oaf-ior-fd=28
redhat 3084 0.8 0.5 11620 gnome-panel
redhat 3146 0.7 0.5 11176 nm-applet --sm-disable
redhat 3133 0.4 0.5 10428 gnome-volume-control-applet

NB: The moral of this story is that process memory usage on Linux is a complex matter; you can't just run ps and know what is going on. This is especially true when you deal with programs that create a lot of identical children processes, like Java. Ps command might report that each Java process uses 100 megabytes of memory, when the reality might be that the marginal cost of each Java process is 10 megabyte of memory.

Una línea a continuación le dará una instantánea detallada de lo que está pasando debajo de las sábanas del núcleo:

for i in `ps -eaf | grep java | grep -v grep | awk '{print $2}'`; do  echo -n "PID $i actual memory  usage is :" >> totaluse.txt; pmap -d $i | grep -i "writeable/private: " >> totaluse.txt; done

Ahora no temas a través de esa línea, ya que la dividiré en pedazos para explicar cada parte y luego podrás ver lo fácil que es usar esas líneas en algunos de los escenarios de producción más críticos, aquí hablé de pmap, vamos a presentarle pmap y definirlo oficialmente según la página MAN:

NAME
PMAP - REPORT MEMORY MAP OF A PROCESS

SYNOPSIS
PMAP [ -X | -D ] [ -Q ] PIDS...
PMAP -V

DESCRIPTION
THE PMAP COMMAND REPORTS THE MEMORY MAP OF A PROCESS OR PROCESSES.

GENERAL OPTIONS
-X EXTENDED SHOW THE EXTENDED FORMAT.
-D DEVICE SHOW THE DEVICE FORMAT.
-Q QUIET DO NOT DISPLAY SOME HEADER/FOOTER LINES.
-V SHOW VERSION DISPLAYS VERSION OF PROGRAM.

EXTENDED AND DEVICE FORMAT FIELDS
ADDRESS: START ADDRESS OF MAP
KBYTES: SIZE OF MAP IN KILOBYTES
RSS: RESIDENT SET SIZE IN KILOBYTES
DIRTY: DIRTY PAGES (BOTH SHARED AND PRIVATE) IN KILOBYTES
MODE: PERMISSIONS ON MAP: READ, WRITE, EXECUTE, SHARED, PRIVATE (COPY ON WRITE)
MAPPING: FILE BACKING THE MAP, OR ’[ ANON ]’ FOR ALLOCATED MEMORY, OR ’[ STACK ]’ FOR THE PROGRAM STACK
OFFSET: OFFSET INTO THE FILE
DEVICE: DEVICE NAME (MAJOR:MINOR)

Para que podamos ver el mapa de proceso de cualquier proceso y su consumo de memoria real y no el promedio vago informado por el proceso superior, tomaré un escenario de producción para explicar mi línea anterior y otros cálculos de memoria basados ​​en herramientas de memoria como gratis.

Scenarios : its difficult to find the actual memory consumption as top is reporting memory usage is 98% utilized and free is also aligning with the top output with no process running in the system other than the system processes, what could be the reason and how to debug it.

Filosofía Linux

La filosofía en Linux es que un recurso no utilizado es un recurso desperdiciado. Por lo tanto, el núcleo utilizará tanta RAM como pueda para almacenar en caché información de sus sistemas de archivos y discos locales y remotos. Esto se acumula con el tiempo a medida que se realizan lecturas y escrituras en el sistema, tratando de mantener los datos almacenados en la RAM lo más relevantes posible para los procesos que se han estado ejecutando en su sistema. El sistema informa de este almacenamiento en caché como la suma de dos números, búferes y caché de página. La caché se recupera, no en el momento de la salida del proceso (es posible que pronto inicie otro proceso que necesite los mismos datos), sino a pedido, es decir, cuando inicie un proceso que necesita mucha memoria para ejecutarse, el kernel de Linux recuperar la memoria que había estado almacenando datos en caché y dársela al nuevo proceso

Dicho esto, hay algunas cosas que se informan como ‘almacenadas en caché’ pero que no están directamente disponibles para el kernel:

1. mmaps anónimos, que no están respaldados por un archivo sino por el área de intercambio.

2. regiones de memoria compartida, tanto System V IPC como POSIX / dev / shm.

3. Algunos servidores de aplicaciones y bases de datos (por ejemplo, SAP y Oracle DB) utilizan esas funciones de memoria compartida como una forma muy conveniente de compartir datos entre múltiples procesos.

Aunque tanto los mmaps anónimos como las regiones de memoria compartida se pueden intercambiar de la memoria al disco, por lo que, en teoría, sus aplicaciones podrían usar esa memoria, es probable que su sistema experimente problemas de rendimiento si eso ocurre.

Por lo tanto, si su sistema está utilizando cualquiera de las funciones anteriores, debe tener en cuenta que no toda la memoria informada como «almacenada en caché» debe contabilizarse como disponible para sus aplicaciones.

Sin embargo, estos informarán sobre todos los procesos adjuntos a ellos, a diferencia de la caché normal que no forma parte del espacio de direcciones de ningún proceso en ejecución, sino que es simplemente una asignación del kernel.

Por ejemplo (las unidades están en megabytes):

# free -m
total used free shared buffers cached
Mem: 1000 900 100 0 350 350
-/+ buffers/cache: 200 800

En este ejemplo, en lo que respecta a las aplicaciones, el sistema está usando solo 200 MB de memoria y tiene 800 MB libres y disponibles para su uso si es necesario (siempre que no existan mapas de memoria anónimos o regiones de memoria compartida).

Nota: en este ejemplo,

Total Physical Memory = 1000 M

Physically Used Memory = 900 M

Actual used memory = 200 M

buffers = 350 M

cached = 350 M

Physically Free Memory = 100 M

Memory free for Applications = 800 M

Los elementos a tener en cuenta aquí son:

<Physically Used Memory> = <Actual used memory> + <buffers> + <cache> = 200 + 350 + 350 = 900 M

<Physically Free Memory> = <Total Physical Memory> - <Actual used memory> - <buffers> - <cache> = 1000 - 200 - 350 - 350 = 100 M

<Memory free for Applications> = <Total Physical Memory> - <Actual used memory> = 1000 - 200 = 800 M

<Memory used  by Applications> = <Physically Used Memory> - <buffers> - <cache> = 900 - 350 - 350 = 200 M

El escenario anterior explica un ejemplo perfecto de uso de herramientas gratuitas, porque la comprensión de todos y cada uno de los parámetros del resultado puede derivar en conclusiones asombrosas y puede reducir el capital total de gastos de actualización del servidor en el mismo.

Podemos explicar un poco de una sola línea aquí ahora, en caso de que se requiera el mapa de proceso detallado para los cálculos anteriores, se requiere un poco de scripts de shell bash y puede obtener valores “fuera de serie” para el rendimiento de su sistema, vamos Eche un vistazo a la explicación a continuación, se puede ver el mapa de proceso para cada proceso del sistema con este revestimiento y luego se pueden agregar las secciones a continuación para obtener el uso de la memoria del sistema o de la aplicación si desea evitar los cálculos de herramientas gratuitas anteriores.

Uso de Pmap

for i in `ps -eaf | grep “any application process” | grep -v grep | awk '{print $2}'`; do echo -n "PID $i actual memory usage is :" >> totaluse.txt; pmap -d $i | grep -i "writeable/private: " >> totaluse.txt; done

Ahora, el mismo parámetro «Memoria utilizada por las aplicaciones» se puede confirmar doblemente con una línea anterior también si tiene tiempo y desea una explicación precisa del uso de la memoria por aplicación o proceso del sistema, por lo que al hacer un gato en totaluse.txt, verá algo como esto:

{a continuación es solo un ejemplo y no tiene nada que ver con el cálculo anterior}

PID 16156 actual memory usage is :mapped: 15128K writeable/private: 10824K shared: 28K
PID 16158 actual memory usage is :mapped: 1381472K writeable/private: 1349680K shared: 2676K
PID 20220 actual memory usage is :mapped: 15196K writeable/private: 10892K shared: 28K
PID 20222 actual memory usage is :mapped: 2733700K writeable/private: 2708256K shared: 2932K
PID 27764 actual memory usage is :mapped: 15196K writeable/private: 10892K shared: 28K
PID 27766 actual memory usage is :mapped: 277176K writeable/private: 255552K shared: 3360K

Ahora, si suma las secciones de escritura / privadas, obtendrá el uso de memoria exacto de los procesos IV, espero que esto ayude. Agregando esas columnas, se acerca a 4 + GB, 10824 + 1349680 + 10892 + 2708256 + 10892 + 255552 KB de memoria === acercándose a 4+ GB.

Para concluir, aquí hemos discutido free y pmap para obtener la utilización exacta de la memoria y podemos evitar los vagos resultados máximos en escenarios de producción críticos.