¿Cómo medir el uso real de la memoria de una aplicación o proceso?

Esta pregunta se trata aquí con gran detalle.

¿Cómo se mide el uso de memoria de una aplicación o proceso en Linux?

Del artículo de blog de Entender el uso de memoria en Linux , ps no es una herramienta precisa para usar con este propósito.

Por qué ps está “equivocado”

Dependiendo de cómo lo mire, ps no informa el uso real de la memoria de los procesos. Lo que realmente está haciendo es mostrar cuánta memoria real tomaría cada proceso si fuera el único proceso en ejecución . Por supuesto, una máquina Linux típica tiene varias docenas de procesos ejecutándose en un momento dado, lo que significa que los números VSZ y RSS informados por ps son casi definitivamente incorrectos .

Con ps o herramientas similares, solo obtendrá la cantidad de páginas de memoria asignadas por ese proceso. Este número es correcto, pero:

  • no refleja la cantidad real de memoria utilizada por la aplicación, solo la cantidad de memoria reservada para ella

  • puede ser engañoso si las páginas se comparten, por ejemplo, mediante varios subprocesos o mediante el uso de bibliotecas vinculadas dinámicamente

Si realmente desea saber qué cantidad de memoria realmente usa su aplicación, debe ejecutarla dentro de un generador de perfiles. Por ejemplo, valgrind puede darle información sobre la cantidad de memoria utilizada y, lo que es más importante, sobre las posibles pérdidas de memoria en su progtwig. La herramienta de perfilador de montón de valgrind se llama ‘macizo’:

Massif es un perfilador de montón. Realiza perfiles de montón detallados tomando instantáneas regulares del montón de un progtwig. Produce un gráfico que muestra el uso del montón a lo largo del tiempo, incluida la información sobre qué partes del progtwig son responsables de la mayoría de las asignaciones de memoria. El gráfico se complementa con un archivo de texto o HTML que incluye más información para determinar dónde se asigna la mayor cantidad de memoria. Massif ejecuta progtwigs aproximadamente 20 veces más lento de lo normal.

Como se explica en la documentación de valgrind , debe ejecutar el progtwig a través de valgrind:

 valgrind --tool=massif   

Massif escribe un volcado de instantáneas de uso de memoria (por ejemplo, massif.out.12345 ). Estos proporcionan, (1) una línea de tiempo de uso de memoria, (2) para cada instantánea, un registro de dónde se asignó la memoria de su progtwig. Una gran herramienta gráfica para analizar estos archivos es massif-visualizer . Pero me encontré con que ms_print , una sencilla herramienta basada en texto enviada con valgrind, ya es de gran ayuda.

Para encontrar pérdidas de memoria, use la herramienta de comprobación de memoria (predeterminada) de valgrind.

Pruebe el comando pmap :

 sudo pmap -x  

Es difícil de decir con certeza, pero aquí hay dos cosas “cercanas” que pueden ayudar.

 $ ps aux 

le dará tamaño virtual (VSZ)

También puede obtener estadísticas detalladas del sistema de archivos / proc yendo a /proc/$pid/status

El más importante es VmSize, que debe estar cerca de lo que da ps aux .

 / proc / 19420 $ estado de gato
 Nombre: firefox
 Estado: S (durmiendo)
 Tid: 19420
 Pid: 19420
 PPid: 1
 TracerPid: 0
 Uid: 1000 1000 1000 1000
 Gid: 1000 1000 1000 1000
 FDSize: 256
 Grupos: 4 6 20 24 25 29 30 44 46 107 109 115 124 1000 
 VmPeak: 222956 kB
 VmSize: 212520 kB
 VmLck: 0 kB
 VmHWM: 127912 kB
 VmRSS: 118768 kB
 VmData: 170180 kB
 VmStk: 228 kB
 VmExe: 28 kB
 VmLib: 35424 kB
 VmPTE: 184 kB
 Hilos: 8
 SigQ: 0/16382
 SigPnd: 0000000000000000
 ShdPnd: 0000000000000000
 SigBlk: 0000000000000000
 SigIgn: 0000000020001000
 SigCgt: 000000018000442f
 CapInh: 0000000000000000
 CapPrm: 0000000000000000
 CapEff: 0000000000000000
 Cpus_allowed: 03
 Mems_allowed: 1
 voluntary_ctxt_switches: 63422
 nonvoluntary_ctxt_switches: 7171

En versiones recientes de Linux, use el subsistema smaps . Por ejemplo, para un proceso con un PID de 1234:

 cat /proc/1234/smaps 

Le dirá exactamente cuánta memoria está usando en ese momento. Lo que es más importante, dividirá la memoria en privada y compartida, para que pueda saber cuánta memoria está usando su instancia del progtwig, sin incluir la memoria compartida entre varias instancias del progtwig.

No hay una manera fácil de calcular esto. Pero algunas personas han tratado de obtener algunas buenas respuestas:

  • ps_mem.py
  • ps_mem.py en github

Use smem , que es una alternativa a ps que calcula el USS y el PSS por proceso. Lo que quieres es probablemente el PSS.

  • USS – Tamaño de conjunto único. Esta es la cantidad de memoria no compartida exclusiva de ese proceso (piénselo como U para memoria única ). No incluye memoria compartida. Por lo tanto, esto subestimará la cantidad de memoria que usa un proceso, pero es útil cuando desea ignorar la memoria compartida.

  • PSS : tamaño de conjunto proporcional. Esto es lo que quieres. Agrega la memoria única (USS), junto con una proporción de su memoria compartida dividida por el número de otros procesos que comparten esa memoria. Por lo tanto, le dará una representación precisa de la cantidad de memoria física real que se utiliza por proceso, con la memoria compartida verdaderamente representada como compartida. Piensa que el P es para la memoria física .

Cómo esto se compara con RSS según lo informado por ps y otras utilidades:

  • RSS – Tamaño del conjunto de residentes. Esta es la cantidad de memoria compartida más memoria no compartida utilizada por cada proceso. Si algún proceso comparte memoria, esto sobre- informará la cantidad de memoria realmente utilizada, ya que la misma memoria compartida se contará más de una vez, volviendo a aparecer en cada proceso que comparte la misma memoria. Por lo tanto, es bastante poco confiable, especialmente cuando los procesos de memoria alta tienen muchas horquillas, lo cual es común en un servidor, con procesos como Apache o PHP (fastcgi / FPM).

Aviso: smem también puede (opcionalmente) generar gráficos como gráficos circulares y similares. IMO no necesitas nada de eso. Si solo desea usarlo desde la línea de comando como si fuera ps -A v, entonces no necesita instalar la dependencia recomendada de python-matplotlib.

¿Qué hay del time ?

No es el time incorporado Bash sino el que puede encontrar con which time , por ejemplo /usr/bin/time

Esto es lo que cubre, en un simple ls :

 $ /usr/bin/time --verbose ls (...) Command being timed: "ls" User time (seconds): 0.00 System time (seconds): 0.00 Percent of CPU this job got: 0% Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.00 Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 2372 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 1 Minor (reclaiming a frame) page faults: 121 Voluntary context switches: 2 Involuntary context switches: 9 Swaps: 0 File system inputs: 256 File system outputs: 0 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0 
 ps -eo size,pid,user,command --sort -size | awk '{ hr=$1/1024 ; printf("%13.2f Mb ",hr) } { for ( x=4 ; x< =NF ; x++ ) { printf("%s ",$x) } print "" }' |cut -d "" -f2 | cut -d "-" -f1 

Úselo como root y puede obtener un resultado claro para el uso de memoria en cada proceso.

EJEMPLO DE SALIDA:

  0.00 Mb COMMAND 1288.57 Mb /usr/lib/firefox 821.68 Mb /usr/lib/chromium/chromium 762.82 Mb /usr/lib/chromium/chromium 588.36 Mb /usr/sbin/mysqld 547.55 Mb /usr/lib/chromium/chromium 523.92 Mb /usr/lib/tracker/tracker 476.59 Mb /usr/lib/chromium/chromium 446.41 Mb /usr/bin/gnome 421.62 Mb /usr/sbin/libvirtd 405.11 Mb /usr/lib/chromium/chromium 302.60 Mb /usr/lib/chromium/chromium 291.46 Mb /usr/lib/chromium/chromium 284.56 Mb /usr/lib/chromium/chromium 238.93 Mb /usr/lib/tracker/tracker 223.21 Mb /usr/lib/chromium/chromium 197.99 Mb /usr/lib/chromium/chromium 194.07 Mb conky 191.92 Mb /usr/lib/chromium/chromium 190.72 Mb /usr/bin/mongod 169.06 Mb /usr/lib/chromium/chromium 155.11 Mb /usr/bin/gnome 136.02 Mb /usr/lib/chromium/chromium 125.98 Mb /usr/lib/chromium/chromium 103.98 Mb /usr/lib/chromium/chromium 93.22 Mb /usr/lib/tracker/tracker 89.21 Mb /usr/lib/gnome 80.61 Mb /usr/bin/gnome 77.73 Mb /usr/lib/evolution/evolution 76.09 Mb /usr/lib/evolution/evolution 72.21 Mb /usr/lib/gnome 69.40 Mb /usr/lib/evolution/evolution 68.84 Mb nautilus 68.08 Mb zeitgeist 60.97 Mb /usr/lib/tracker/tracker 59.65 Mb /usr/lib/evolution/evolution 57.68 Mb apt 55.23 Mb /usr/lib/gnome 53.61 Mb /usr/lib/evolution/evolution 53.07 Mb /usr/lib/gnome 52.83 Mb /usr/lib/gnome 51.02 Mb /usr/lib/udisks2/udisksd 50.77 Mb /usr/lib/evolution/evolution 50.53 Mb /usr/lib/gnome 50.45 Mb /usr/lib/gvfs/gvfs 50.36 Mb /usr/lib/packagekit/packagekitd 50.14 Mb /usr/lib/gvfs/gvfs 48.95 Mb /usr/bin/Xwayland :1024 46.21 Mb /usr/bin/gnome 42.43 Mb /usr/bin/zeitgeist 42.29 Mb /usr/lib/gnome 41.97 Mb /usr/lib/gnome 41.64 Mb /usr/lib/gvfs/gvfsd 41.63 Mb /usr/lib/gvfs/gvfsd 41.55 Mb /usr/lib/gvfs/gvfsd 41.48 Mb /usr/lib/gvfs/gvfsd 39.87 Mb /usr/bin/python /usr/bin/chrome 37.45 Mb /usr/lib/xorg/Xorg vt2 36.62 Mb /usr/sbin/NetworkManager 35.63 Mb /usr/lib/caribou/caribou 34.79 Mb /usr/lib/tracker/tracker 33.88 Mb /usr/sbin/ModemManager 33.77 Mb /usr/lib/gnome 33.61 Mb /usr/lib/upower/upowerd 33.53 Mb /usr/sbin/gdm3 33.37 Mb /usr/lib/gvfs/gvfsd 33.36 Mb /usr/lib/gvfs/gvfs 33.23 Mb /usr/lib/gvfs/gvfs 33.15 Mb /usr/lib/at 33.15 Mb /usr/lib/at 30.03 Mb /usr/lib/colord/colord 29.62 Mb /usr/lib/apt/methods/https 28.06 Mb /usr/lib/zeitgeist/zeitgeist 27.29 Mb /usr/lib/policykit 25.55 Mb /usr/lib/gvfs/gvfs 25.55 Mb /usr/lib/gvfs/gvfs 25.23 Mb /usr/lib/accountsservice/accounts 25.18 Mb /usr/lib/gvfs/gvfsd 25.15 Mb /usr/lib/gvfs/gvfs 25.15 Mb /usr/lib/gvfs/gvfs 25.12 Mb /usr/lib/gvfs/gvfs 25.10 Mb /usr/lib/gnome 25.10 Mb /usr/lib/gnome 25.07 Mb /usr/lib/gvfs/gvfsd 24.99 Mb /usr/lib/gvfs/gvfs 23.26 Mb /usr/lib/chromium/chromium 22.09 Mb /usr/bin/pulseaudio 19.01 Mb /usr/bin/pulseaudio 18.62 Mb (sd 18.46 Mb (sd 18.30 Mb /sbin/init 18.17 Mb /usr/sbin/rsyslogd 17.50 Mb gdm 17.42 Mb gdm 17.09 Mb /usr/lib/dconf/dconf 17.09 Mb /usr/lib/at 17.06 Mb /usr/lib/gvfs/gvfsd 16.98 Mb /usr/lib/at 16.91 Mb /usr/lib/gdm3/gdm 16.86 Mb /usr/lib/gvfs/gvfsd 16.86 Mb /usr/lib/gdm3/gdm 16.85 Mb /usr/lib/dconf/dconf 16.85 Mb /usr/lib/dconf/dconf 16.73 Mb /usr/lib/rtkit/rtkit 16.69 Mb /lib/systemd/systemd 13.13 Mb /usr/lib/chromium/chromium 13.13 Mb /usr/lib/chromium/chromium 10.92 Mb anydesk 8.54 Mb /sbin/lvmetad 7.43 Mb /usr/sbin/apache2 6.82 Mb /usr/sbin/apache2 6.77 Mb /usr/sbin/apache2 6.73 Mb /usr/sbin/apache2 6.66 Mb /usr/sbin/apache2 6.64 Mb /usr/sbin/apache2 6.63 Mb /usr/sbin/apache2 6.62 Mb /usr/sbin/apache2 6.51 Mb /usr/sbin/apache2 6.25 Mb /usr/sbin/apache2 6.22 Mb /usr/sbin/apache2 3.92 Mb bash 3.14 Mb bash 2.97 Mb bash 2.95 Mb bash 2.93 Mb bash 2.91 Mb bash 2.86 Mb bash 2.86 Mb bash 2.86 Mb bash 2.84 Mb bash 2.84 Mb bash 2.45 Mb /lib/systemd/systemd 2.30 Mb (sd 2.28 Mb /usr/bin/dbus 1.84 Mb /usr/bin/dbus 1.46 Mb ps 1.21 Mb openvpn hackthebox.ovpn 1.16 Mb /sbin/dhclient 1.16 Mb /sbin/dhclient 1.09 Mb /lib/systemd/systemd 0.98 Mb /sbin/mount.ntfs /dev/sda3 /media/n0bit4/Data 0.97 Mb /lib/systemd/systemd 0.96 Mb /lib/systemd/systemd 0.89 Mb /usr/sbin/smartd 0.77 Mb /usr/bin/dbus 0.76 Mb su 0.76 Mb su 0.76 Mb su 0.76 Mb su 0.76 Mb su 0.76 Mb su 0.75 Mb sudo su 0.75 Mb sudo su 0.75 Mb sudo su 0.75 Mb sudo su 0.75 Mb sudo su 0.75 Mb sudo su 0.74 Mb /usr/bin/dbus 0.71 Mb /usr/lib/apt/methods/http 0.68 Mb /bin/bash /usr/bin/mysqld_safe 0.68 Mb /sbin/wpa_supplicant 0.66 Mb /usr/bin/dbus 0.61 Mb /lib/systemd/systemd 0.54 Mb /usr/bin/dbus 0.46 Mb /usr/sbin/cron 0.45 Mb /usr/sbin/irqbalance 0.43 Mb logger 0.41 Mb awk { hr=$1/1024 ; printf("%13.2f Mb ",hr) } { for ( x=4 ; x< =NF ; x++ ) { printf("%s ",$x) } print "" } 0.40 Mb /usr/bin/ssh 0.34 Mb /usr/lib/chromium/chrome 0.32 Mb cut 0.32 Mb cut 0.00 Mb [kthreadd] 0.00 Mb [ksoftirqd/0] 0.00 Mb [kworker/0:0H] 0.00 Mb [rcu_sched] 0.00 Mb [rcu_bh] 0.00 Mb [migration/0] 0.00 Mb [lru 0.00 Mb [watchdog/0] 0.00 Mb [cpuhp/0] 0.00 Mb [cpuhp/1] 0.00 Mb [watchdog/1] 0.00 Mb [migration/1] 0.00 Mb [ksoftirqd/1] 0.00 Mb [kworker/1:0H] 0.00 Mb [cpuhp/2] 0.00 Mb [watchdog/2] 0.00 Mb [migration/2] 0.00 Mb [ksoftirqd/2] 0.00 Mb [kworker/2:0H] 0.00 Mb [cpuhp/3] 0.00 Mb [watchdog/3] 0.00 Mb [migration/3] 0.00 Mb [ksoftirqd/3] 0.00 Mb [kworker/3:0H] 0.00 Mb [kdevtmpfs] 0.00 Mb [netns] 0.00 Mb [khungtaskd] 0.00 Mb [oom_reaper] 0.00 Mb [writeback] 0.00 Mb [kcompactd0] 0.00 Mb [ksmd] 0.00 Mb [khugepaged] 0.00 Mb [crypto] 0.00 Mb [kintegrityd] 0.00 Mb [bioset] 0.00 Mb [kblockd] 0.00 Mb [devfreq_wq] 0.00 Mb [watchdogd] 0.00 Mb [kswapd0] 0.00 Mb [vmstat] 0.00 Mb [kthrotld] 0.00 Mb [ipv6_addrconf] 0.00 Mb [acpi_thermal_pm] 0.00 Mb [ata_sff] 0.00 Mb [scsi_eh_0] 0.00 Mb [scsi_tmf_0] 0.00 Mb [scsi_eh_1] 0.00 Mb [scsi_tmf_1] 0.00 Mb [scsi_eh_2] 0.00 Mb [scsi_tmf_2] 0.00 Mb [scsi_eh_3] 0.00 Mb [scsi_tmf_3] 0.00 Mb [scsi_eh_4] 0.00 Mb [scsi_tmf_4] 0.00 Mb [scsi_eh_5] 0.00 Mb [scsi_tmf_5] 0.00 Mb [bioset] 0.00 Mb [kworker/1:1H] 0.00 Mb [kworker/3:1H] 0.00 Mb [kworker/0:1H] 0.00 Mb [kdmflush] 0.00 Mb [bioset] 0.00 Mb [kdmflush] 0.00 Mb [bioset] 0.00 Mb [jbd2/sda5 0.00 Mb [ext4 0.00 Mb [kworker/2:1H] 0.00 Mb [kauditd] 0.00 Mb [bioset] 0.00 Mb [drbd 0.00 Mb [irq/27 0.00 Mb [i915/signal:0] 0.00 Mb [i915/signal:1] 0.00 Mb [i915/signal:2] 0.00 Mb [ttm_swap] 0.00 Mb [cfg80211] 0.00 Mb [kworker/u17:0] 0.00 Mb [hci0] 0.00 Mb [hci0] 0.00 Mb [kworker/u17:1] 0.00 Mb [iprt 0.00 Mb [iprt 0.00 Mb [kworker/1:0] 0.00 Mb [kworker/3:0] 0.00 Mb [kworker/0:0] 0.00 Mb [kworker/2:0] 0.00 Mb [kworker/u16:0] 0.00 Mb [kworker/u16:2] 0.00 Mb [kworker/3:2] 0.00 Mb [kworker/2:1] 0.00 Mb [kworker/1:2] 0.00 Mb [kworker/0:2] 0.00 Mb [kworker/2:2] 0.00 Mb [kworker/0:1] 0.00 Mb [scsi_eh_6] 0.00 Mb [scsi_tmf_6] 0.00 Mb [usb 0.00 Mb [bioset] 0.00 Mb [kworker/3:1] 0.00 Mb [kworker/u16:1] 

Este es un excelente resumen de las herramientas y problemas: enlace archive.org

Lo citaré, para que más desarrolladores realmente lo lean.

Si desea analizar el uso de memoria de todo el sistema o analizar minuciosamente el uso de memoria de una aplicación (no solo su uso de stack), utilice exmap . Para el análisis de todo el sistema, encuentre procesos con el uso efectivo más alto, tome la mayor parte de la memoria en la práctica, encuentre procesos con el mayor uso grabable, cree la mayor cantidad de datos (y por lo tanto posiblemente tenga fugas o sean muy ineficaces en el uso de datos). Seleccione dicha aplicación y analice sus asignaciones en la segunda lista. Vea la sección de exmap para más detalles. También use xrestp para verificar el alto uso de recursos X, especialmente si el proceso del servidor X requiere mucha memoria. Ver la sección xrestp para más detalles.

Si quiere detectar fugas, use valgrind o posiblemente kmtrace .

Si desea analizar el uso del montón (malloc, etc.) de una aplicación, ejecútelo en memprof o con kmtrace , perfile la aplicación y busque en el árbol de llamadas de función las asignaciones más grandes. Ver sus secciones para más detalles.

Además de las soluciones enumeradas en sus respuestas, puede usar el comando de Linux “arriba”; Proporciona una vista dinámica en tiempo real del sistema en ejecución, proporciona el uso de CPU y memoria, para todo el sistema junto con para cada progtwig, en porcentaje:

 top 

filtrar por un progtwig pid:

 top -p  

para filtrar por un nombre de progtwig:

 top | grep  

“arriba” también proporciona algunos campos como:

VIRT – Imagen virtual (kb): la cantidad total de memoria virtual utilizada por la tarea

RES – Tamaño del residente (kb): la memoria física no intercambiada que ha utilizado una tarea; RES = CÓDIGO + DATOS.

DATA – Data + Stack size (kb): la cantidad de memoria física dedicada a un código que no sea ejecutable, también conocido como tamaño de “data resident set” o DRS.

SHR – Tamaño de memoria compartida (kb): la cantidad de memoria compartida utilizada por una tarea. Simplemente refleja la memoria que podría compartirse potencialmente con otros procesos.

Referencia aquí .

No hay una sola respuesta para esto porque no se puede señalar con precisión la cantidad de memoria que utiliza un proceso. La mayoría de los procesos bajo Linux usan bibliotecas compartidas. Por ejemplo, supongamos que desea calcular el uso de memoria para el proceso ‘ls’. ¿Cuenta solo la memoria utilizada por el ejecutable ‘ls’ (si puede aislarlo)? ¿Qué hay de libc? ¿O todas estas otras librerías que se requieren para ejecutar ‘ls’?

 linux-gate.so.1 => (0x00ccb000) librt.so.1 => /lib/librt.so.1 (0x06bc7000) libacl.so.1 => /lib/libacl.so.1 (0x00230000) libselinux.so.1 => /lib/libselinux.so.1 (0x00162000) libc.so.6 => /lib/libc.so.6 (0x00b40000) libpthread.so.0 => /lib/libpthread.so.0 (0x00cb4000) /lib/ld-linux.so.2 (0x00b1d000) libattr.so.1 => /lib/libattr.so.1 (0x00229000) libdl.so.2 => /lib/libdl.so.2 (0x00cae000) libsepol.so.1 => /lib/libsepol.so.1 (0x0011a000) 

Podría argumentar que otros procesos los comparten, pero no se pueden ejecutar ‘ls’ en el sistema sin que se carguen.

Además, si necesita saber cuánta memoria necesita un proceso para planificar la capacidad, debe calcular cuánto utiliza cada copia adicional del proceso. Creo que el estado de / proc / PID / podría darle suficiente información del uso de memoria en una sola vez. Por otro lado, valgrind le dará un mejor perfil del uso de memoria a lo largo de la vida útil del progtwig

Si su código está en C o C ++, es posible que pueda usar getrusage() que le devuelve varias estadísticas sobre la memoria y el uso del tiempo de su proceso.

Sin embargo, no todas las plataformas admiten esto y devolverán 0 valores para las opciones de uso de memoria.

En su lugar, puede ver el archivo virtual creado en /proc/[pid]/statm (donde [pid] se reemplaza por su id de proceso. Puede obtenerlo de getpid() ).

Este archivo se verá como un archivo de texto con 7 enteros. Probablemente le interesen más los números de la primera (uso de toda la memoria) y la sexta (uso de la memoria de datos) en este archivo.

Valgrind puede mostrar información detallada, pero ralentiza significativamente la aplicación objective, y la mayoría de las veces cambia el comportamiento de la aplicación.
Exmap era algo que aún no sabía, pero parece que necesitas un módulo kernel para obtener la información, lo que puede ser un obstáculo.

Supongo que lo que todos quieren saber El “uso de memoria” de WRT es el siguiente …
En Linux, la cantidad de memoria física que puede usar un solo proceso se puede dividir aproximadamente en las siguientes categorías.

  • Ma memoria anónima mapeada

    • .p privado
      • .d dirty == malloc / mmapped montón y astackr memoria asignada y escrita
      • .c clean == Malloc / mmapped montón y stack de memoria una vez asignado, escrito, luego liberado, pero no recuperado todavía
    • .s compartido
      • .d dirty == malloc / mmaped heap podría obtener copy-on-write y compartirse entre procesos (editado)
      • .c clean == malloc / mmaped heap podría obtener copy-on-write y compartirse entre procesos (editado)
  • Mn llamado memoria mapeada

    • .p privado
      • .d dirty == archivo mmapped escrito memoria privada
      • .c clean == progtwig mapeado / texto de biblioteca privado mapeado
    • .s compartido
      • .d dirty == archivo mmapped memoria escrita compartida
      • .c clean == mapped library text shared mapped

La utilidad incluida en Android llamada showmap es bastante útil

 virtual shared shared private private size RSS PSS clean dirty clean dirty object -------- -------- -------- -------- -------- -------- -------- ------------------------------ 4 0 0 0 0 0 0 0:00 0 [vsyscall] 4 4 0 4 0 0 0 [vdso] 88 28 28 0 0 4 24 [stack] 12 12 12 0 0 0 12 7909 /lib/ld-2.11.1.so 12 4 4 0 0 0 4 89529 /usr/lib/locale/en_US.utf8/LC_IDENTIFICATION 28 0 0 0 0 0 0 86661 /usr/lib/gconv/gconv-modules.cache 4 0 0 0 0 0 0 87660 /usr/lib/locale/en_US.utf8/LC_MEASUREMENT 4 0 0 0 0 0 0 89528 /usr/lib/locale/en_US.utf8/LC_TELEPHONE 4 0 0 0 0 0 0 89527 /usr/lib/locale/en_US.utf8/LC_ADDRESS 4 0 0 0 0 0 0 87717 /usr/lib/locale/en_US.utf8/LC_NAME 4 0 0 0 0 0 0 87873 /usr/lib/locale/en_US.utf8/LC_PAPER 4 0 0 0 0 0 0 13879 /usr/lib/locale/en_US.utf8/LC_MESSAGES/SYS_LC_MESSAGES 4 0 0 0 0 0 0 89526 /usr/lib/locale/en_US.utf8/LC_MONETARY 4 0 0 0 0 0 0 89525 /usr/lib/locale/en_US.utf8/LC_TIME 4 0 0 0 0 0 0 11378 /usr/lib/locale/en_US.utf8/LC_NUMERIC 1156 8 8 0 0 4 4 11372 /usr/lib/locale/en_US.utf8/LC_COLLATE 252 0 0 0 0 0 0 11321 /usr/lib/locale/en_US.utf8/LC_CTYPE 128 52 1 52 0 0 0 7909 /lib/ld-2.11.1.so 2316 32 11 24 0 0 8 7986 /lib/libncurses.so.5.7 2064 8 4 4 0 0 4 7947 /lib/libdl-2.11.1.so 3596 472 46 440 0 4 28 7933 /lib/libc-2.11.1.so 2084 4 0 4 0 0 0 7995 /lib/libnss_compat-2.11.1.so 2152 4 0 4 0 0 0 7993 /lib/libnsl-2.11.1.so 2092 0 0 0 0 0 0 8009 /lib/libnss_nis-2.11.1.so 2100 0 0 0 0 0 0 7999 /lib/libnss_files-2.11.1.so 3752 2736 2736 0 0 864 1872 [heap] 24 24 24 0 0 0 24 [anon] 916 616 131 584 0 0 32 /bin/bash -------- -------- -------- -------- -------- -------- -------- ------------------------------ 22816 4004 3005 1116 0 876 2012 TOTAL 

Estoy usando htop ; es un progtwig de consola muy bueno similar al Administrador de tareas de Windows.

Valgrind es increíble si tienes tiempo para ejecutarlo. valgrind --tool=massif es la solución correcta.

Sin embargo, estoy empezando a ejecutar ejemplos más grandes, y el uso de valgrind ya no es práctico. ¿Hay alguna manera de decir el uso máximo de memoria (módulo de tamaño de página y páginas compartidas) de un progtwig?

En un sistema unix real, /usr/bin/time -v funciona. En Linux, sin embargo, esto no funciona.

 #!/bin/ksh # # Returns total memory used by process $1 in kb. # # See /proc/NNNN/smaps if you want to do something # more interesting. # IFS=$'\n' for line in $( 

Una buena prueba del uso más del “mundo real” es abrir la aplicación, luego ejecutar vmstat -s y verificar la estadística de “memoria activa”. Cierre la aplicación, espere unos segundos y vuelva a ejecutar vmstat -s . Por mucho que la memoria activa fue liberada, evidentemente estaba en uso por la aplicación.

Tres métodos más para probar:

  1. ps aux --sort pmem
    Clasifica la salida por %MEM .
  2. ps aux | awk '{print $2, $4, $11}' | sort -k2r | head -n 15
    Se ordena usando tubos.
  3. top -a
    Comienza la clasificación superior por %MEM

(Extraído de aquí )

Below command line will give you the total memory used by the various process running on the Linux machine in MB

 ps -eo size,pid,user,command --sort -size | awk '{ hr=$1/1024 ; printf("%13.2f Mb ",hr) } { for ( x=4 ; x< =NF ; x++ ) { printf("%s ",$x) } print "" }' | awk '{total=total + $1} END {print total}' 

Get valgrind. give it your program to run, and it’ll tell you plenty about its memory usage.

This would apply only for the case of a program that runs for some time and stops. I don’t know if valgrind can get its hands on an already-running process or shouldn’t-stop processes such as daemons.

If the process is not using up too much memory (either because you expect this to be the case, or some other command has given this initial indication), and the process can withstand being stopped for a short period of time, you can try to use the gcore command.

 gcore  

Check the size of the generated core file to get a good idea how much memory a particular process is using.

This won’t work too well if process is using hundreds of megs, or gigs, as the core generation could take several seconds or minutes to be created depending on I/O performance. During the core creation the process is stopped (or “frozen”) to prevent memory changes. Así que ten cuidado.

Also make sure the mount point where the core is generated has plenty of disk space and that the system will not react negatively to the core file being created in that particular directory.

Edit: this works 100% well only when memory consumption increases

If you want to monitor memory usage by given process (or group of processed sharing common name, eg google-chrome , you can use my bash-script:

 while true; do ps aux | awk ‚{print $5, $11}' | grep chrome | sort -n > /tmp/a.txt; sleep 1; diff /tmp/{b,a}.txt; mv /tmp/{a,b}.txt; done; 

this will continously look for changes and print them.

enter image description here

If you want something quicker than profiling with Valgrind and your kernel is older and you can’t use smaps, a ps with the options to show the resident set of the process (with ps -o rss,command ) can give you a quick and reasonable _aproximation_ of the real amount of non-swapped memory being used.

Check shell script to check memory usage by application in linux . Also available on github and in a version without paste and bc .

Another vote for valgrind here, but I would like to add that you can use a tool like Alleyoop to help you interpret the results generated by valgrind.

I use the two tools all the time and always have lean, non-leaky code to proudly show for it 😉

While this question seems to be about examining currently running processes, I wanted to see the peak memory used by an application from start to finish. Besides valgrind, you can use tstime , which is much simpler. It measures the “highwater” memory usage (RSS and virtual). From this answer .

I would suggest that you use atop. You can find everything about it on this page . It is capable of providing all the necessary KPI for your processes and it can also capture to a file.

Use the in-built ‘ system monitor ‘ GUI tool available in ubuntu

Based on answer to a related question .

You may use SNMP to get the memory and cpu usage of a process in a particular device in network 🙂

Requisitos:

  • the device running the process should have snmp installed and running
  • snmp should be configured to accept requests from where you will run the script below(it may be configured in snmpd.conf)
  • you should know the process id(pid) of the process you want to monitor

Notas:

  • HOST-RESOURCES-MIB::hrSWRunPerfCPU is the number of centi-seconds of the total system’s CPU resources consumed by this process. Note that on a multi-processor system, this value may increment by more than one centi-second in one centi-second of real (wall clock) time.

  • HOST-RESOURCES-MIB::hrSWRunPerfMem is the total amount of real system memory allocated to this process.

**

Process monitoring script:

**

 echo "IP: " read ip echo "specfiy pid: " read pid echo "interval in seconds:" read interval while [ 1 ] do date snmpget -v2c -c public $ip HOST-RESOURCES-MIB::hrSWRunPerfCPU.$pid snmpget -v2c -c public $ip HOST-RESOURCES-MIB::hrSWRunPerfMem.$pid sleep $interval; done 

/prox/xxx/numa_maps gives some info there: N0=??? N1=???. But this result might be lower than the actual result, as it only count those which have been touched.