Tengo un demonio de Linux que bifurca a algunos niños y los supervisa en caso de fallos (reiniciándose según sea necesario). Será genial si el padre puede supervisar el uso de la memoria de los procesos hijos para detectar fugas de memoria y reiniciar los procesos secundarios cuando vayan más allá de un determinado tamaño. ¿Cómo puedo hacer esto?Supervisar el uso de la memoria del proceso secundario
Usted debe ser capaz de obtener información de la memoria detallada de/proc/{PID}/estado:
Name: bash
State: S (sleeping)
Tgid: 6053
Pid: 6053
PPid: 6050
TracerPid: 0
Uid: 1007 1007 1007 1007
Gid: 1007 1007 1007 1007
FDSize: 256
Groups: 1007
VmPeak: 48076 kB
VmSize: 48044 kB
VmLck: 0 kB
VmHWM: 4932 kB
VmRSS: 2812 kB
VmData: 2232 kB
VmStk: 84 kB
VmExe: 832 kB
VmLib: 6468 kB
VmPTE: 108 kB
Threads: 1
SigQ: 0/8190
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000001010
SigCgt: 0000000188020001
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
Cpus_allowed: 0f
Mems_allowed: 00000000,00000001
voluntary_ctxt_switches: 69227121
nonvoluntary_ctxt_switches: 19071
Sin embargo, a menos que las pérdidas de memoria son dramáticos, es difícil detectarlos mirando estadísticas de procesos, porque malloc y free suelen ser bastante abstractos a partir de las llamadas al sistema (brk/sbrk) a las que corresponden.
También puede verificar en/proc/$ {PID}/statm.
podría intentar tener un script de monitor ejecutando vmstat en paralelo con su proceso (tenga en cuenta que esto no es una buena idea si está ejecutando este script varias veces ya que obtendrá múltiples copias vmstat). A continuación, esta secuencia de comandos del monitor puede tomar la memoria libre más el tamaño del búfer y el caché para obtener la cantidad de memoria que el sistema operativo tiene disponible y puede rastrear eso. Luego, si está por debajo de un umbral, puede verificar los procesos más grandes llamando a ps -e -o ... (consulte la página de manual para obtener detalles, pero pruebe con vsz, pcpu, user, pid, args como punto de partida).
Aconsejo ejecutar este monitor como un proceso separado y hacer que mate el proceso deshonesto cuando se vuelve demasiado grande. Puede restringir el conjunto de procesos monitorizados mediante el parámetro
-u user-name
a ps.
Sin embargo, todo esto es un hack (significado en el Reino Unido): la solución correcta es arreglar las fugas, suponiendo que tenga el código.
Prefiero una solución integrada que no dependa de programas/scripts externos. por supuesto, corregir la fuga de memoria es lo correcto, pero en el mundo real a veces hay que comprometerse temporalmente. también, puedo imaginar casos cuando ejecuta código externo que no está bajo su control (piense que apache ejecuta un script php). –
El problema con una única solución integrada es que se vuelve cada vez más complicado. La ventaja de tener programas separados para hacer funciones separadas es que cada uno es individualmente relativamente simple y fácil de depurar e implementar. Una solución integrada parece buena al principio (no hay problemas con la comunicación, usted sabe que se está ejecutando porque el programa principal se está ejecutando, etc.) pero a medida que su sistema crece, la cuestión de la simplicidad se volverá más y más importante – Nick
no hay llamadas al sistema para hacer eso? analizar archivos parece una forma bastante sucia de obtener la información. –
Así es como ps y amigos obtienen su información ... – WhirlWind
así que supongo que esa es la mejor manera. ¡Gracias! –