mp3tag - mp3 tag linux

¿Qué mató mi proceso y por qué? (12)

Permítanme primero explicar cuándo y por qué invocan a OOMKiller?

Digamos que tienes 512 RAM + 1GB de memoria de intercambio. Entonces, en teoría, su CPU tiene acceso a un total de 1.5 GB de memoria virtual.

Ahora, durante algún tiempo, todo funciona bien dentro de 1.5 GB de memoria total. Pero de repente (o gradualmente), su sistema comenzó a consumir más y más memoria y llegó a un punto en torno al 95% de la memoria total utilizada.

Ahora digamos que cualquier proceso ha solicitado grandes bloqueos de memoria del kernel. Kernel comprueba la memoria disponible y descubre que no hay forma de que pueda asignar más memoria a su proceso. Así que intentará liberar algo de memoria llamando / invocando a OOMKiller ( http://linux-mm.org/OOM ).

OOMKiller tiene su propio algoritmo para calificar el rango en cada proceso. Por lo general, el proceso que utiliza más memoria se convierte en la víctima que se mata

¿Dónde puedo encontrar los registros de OOMKiller?

Típicamente en el directorio / var / log. Ya sea /var/log/kern.log o / var / log / dmesg

Espero que esto te ayudará.

Algunas soluciones típicas:

Aumentar la memoria (no cambiar)
Encuentra las fugas de memoria en tu programa y repáralas.
Restrinja la memoria que puede consumir cualquier proceso (por ejemplo, la memoria JVM se puede restringir utilizando JAVA_OPTS)
Ver los registros y google :)

Mi aplicación se ejecuta como un proceso en segundo plano en Linux. Actualmente se inicia en la línea de comandos en una ventana de Terminal.

Recientemente, un usuario estuvo ejecutando la aplicación por un tiempo y murió misteriosamente. El texto:

Delicado

estaba en la terminal Esto sucedió dos veces. Pregunté si alguien en una Terminal diferente usó el comando kill para matar el proceso. No.

¿Bajo qué condiciones decidirá Linux matar mi proceso? Creo que el shell se mostró "muerto" porque el proceso murió después de recibir la señal de matar (9). Si Linux envió la señal de eliminación, ¿debería haber un mensaje en un registro del sistema en algún lugar que explique por qué se eliminó?

Como han dicho dwc y Adam Jaskiewicz, el culpable es probablemente el asesino de OOM. Sin embargo, la siguiente pregunta que sigue es: ¿Cómo puedo prevenir esto?

Hay varias maneras:

Dale a tu sistema más RAM si puedes (fácil si es una máquina virtual)
Asegúrese de que el asesino de OOM elija un proceso diferente.
Deshabilitar el asesino OOM
Elija una distribución de Linux que se envíe con OOM Killer desactivado.

Encontré (2) que es especialmente fácil de implementar, gracias a este artículo .

El módulo PAM para limitar los recursos causó exactamente los resultados que describiste: Mi proceso murió misteriosamente con el texto Matado en la ventana de la consola. No hay salida de registro, ni en syslog ni en kern.log . El programa top me ayudó a descubrir que exactamente después de un minuto de uso de la CPU, mi proceso se detiene.

El usuario tiene la capacidad de matar sus propios programas, usando kill o Control + C, pero tengo la impresión de que eso no fue lo que sucedió y que el usuario se quejó con usted.

root tiene la capacidad de eliminar programas, por supuesto, pero si alguien tiene root en tu máquina y está matando cosas, tienes mayores problemas.

Si no es el administrador del sistema, es posible que el administrador del sistema haya configurado cuotas en la CPU, la memoria RAM, el uso del disco ort y los procesos de eliminación automática que los superen.

Aparte de esas conjeturas, no estoy seguro sin más información sobre el programa.

En un entorno lsf (interactivo o de otro tipo) si la aplicación supera la utilización de la memoria más allá de un umbral preestablecido por los administradores en la cola o la solicitud de recursos en la cola, los procesos se eliminarán para que otros usuarios no sean víctimas de un potencial huir. No siempre envía un correo electrónico cuando lo hace, dependiendo de cómo esté configurado.

Una solución en este caso es encontrar una cola con recursos más grandes o definir requisitos de recursos más grandes en el envío.

Es posible que también desee revisar man ulimit

Aunque no recuerdo que ulimit resultado en Killed ha pasado un tiempo desde que lo necesitaba.

Este es el administrador de Linux fuera de memoria (OOM) . Su proceso se seleccionó debido a la " maldad ": una combinación de antigüedad, tamaño residente (memoria en uso, en lugar de solo asignación) y otros factores.

sudo journalctl -xb

Verás un mensaje como:

Jul 20 11:05:00 someapp kernel: Mem-Info: Jul 20 11:05:00 someapp kernel: Node 0 DMA per-cpu: Jul 20 11:05:00 someapp kernel: CPU 0: hi: 0, btch: 1 usd: 0 Jul 20 11:05:00 someapp kernel: Node 0 DMA32 per-cpu: Jul 20 11:05:00 someapp kernel: CPU 0: hi: 186, btch: 31 usd: 30 Jul 20 11:05:00 someapp kernel: active_anon:206043 inactive_anon:6347 isolated_anon:0 active_file:722 inactive_file:4126 isolated_file:0 unevictable:0 dirty:5 writeback:0 unstable:0 free:12202 slab_reclaimable:3849 slab_unreclaimable:14574 mapped:792 shmem:12802 pagetables:1651 bounce:0 free_cma:0 Jul 20 11:05:00 someapp kernel: Node 0 DMA free:4576kB min:708kB low:884kB high:1060kB active_anon:10012kB inactive_anon:488kB active_file:4kB inactive_file:4kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present Jul 20 11:05:00 someapp kernel: lowmem_reserve[]: 0 968 968 968 Jul 20 11:05:00 someapp kernel: Node 0 DMA32 free:44232kB min:44344kB low:55428kB high:66516kB active_anon:814160kB inactive_anon:24900kB active_file:2884kB inactive_file:16500kB unevictable:0kB isolated(anon):0kB isolated Jul 20 11:05:00 someapp kernel: lowmem_reserve[]: 0 0 0 0 Jul 20 11:05:00 someapp kernel: Node 0 DMA: 17*4kB (UEM) 22*8kB (UEM) 15*16kB (UEM) 12*32kB (UEM) 8*64kB (E) 9*128kB (UEM) 2*256kB (UE) 3*512kB (UM) 0*1024kB 0*2048kB 0*4096kB = 4580kB Jul 20 11:05:00 someapp kernel: Node 0 DMA32: 216*4kB (UE) 601*8kB (UE) 448*16kB (UE) 311*32kB (UEM) 135*64kB (UEM) 74*128kB (UEM) 5*256kB (EM) 0*512kB 0*1024kB 1*2048kB (R) 0*4096kB = 44232kB Jul 20 11:05:00 someapp kernel: Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB Jul 20 11:05:00 someapp kernel: 17656 total pagecache pages Jul 20 11:05:00 someapp kernel: 0 pages in swap cache Jul 20 11:05:00 someapp kernel: Swap cache stats: add 0, delete 0, find 0/0 Jul 20 11:05:00 someapp kernel: Free swap = 0kB Jul 20 11:05:00 someapp kernel: Total swap = 0kB Jul 20 11:05:00 someapp kernel: 262141 pages RAM Jul 20 11:05:00 someapp kernel: 7645 pages reserved Jul 20 11:05:00 someapp kernel: 264073 pages shared Jul 20 11:05:00 someapp kernel: 240240 pages non-shared Jul 20 11:05:00 someapp kernel: [ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name Jul 20 11:05:00 someapp kernel: [ 241] 0 241 13581 1610 26 0 0 systemd-journal Jul 20 11:05:00 someapp kernel: [ 246] 0 246 10494 133 22 0 -1000 systemd-udevd Jul 20 11:05:00 someapp kernel: [ 264] 0 264 29174 121 26 0 -1000 auditd Jul 20 11:05:00 someapp kernel: [ 342] 0 342 94449 466 67 0 0 NetworkManager Jul 20 11:05:00 someapp kernel: [ 346] 0 346 137495 3125 88 0 0 tuned Jul 20 11:05:00 someapp kernel: [ 348] 0 348 79595 726 60 0 0 rsyslogd Jul 20 11:05:00 someapp kernel: [ 353] 70 353 6986 72 19 0 0 avahi-daemon Jul 20 11:05:00 someapp kernel: [ 362] 70 362 6986 58 18 0 0 avahi-daemon Jul 20 11:05:00 someapp kernel: [ 378] 0 378 1621 25 8 0 0 iprinit Jul 20 11:05:00 someapp kernel: [ 380] 0 380 1621 26 9 0 0 iprupdate Jul 20 11:05:00 someapp kernel: [ 384] 81 384 6676 142 18 0 -900 dbus-daemon Jul 20 11:05:00 someapp kernel: [ 385] 0 385 8671 83 21 0 0 systemd-logind Jul 20 11:05:00 someapp kernel: [ 386] 0 386 31573 153 15 0 0 crond Jul 20 11:05:00 someapp kernel: [ 391] 999 391 128531 2440 48 0 0 polkitd Jul 20 11:05:00 someapp kernel: [ 400] 0 400 9781 23 8 0 0 iprdump Jul 20 11:05:00 someapp kernel: [ 419] 0 419 27501 32 10 0 0 agetty Jul 20 11:05:00 someapp kernel: [ 855] 0 855 22883 258 43 0 0 master Jul 20 11:05:00 someapp kernel: [ 862] 89 862 22926 254 44 0 0 qmgr Jul 20 11:05:00 someapp kernel: [23631] 0 23631 20698 211 43 0 -1000 sshd Jul 20 11:05:00 someapp kernel: [12884] 0 12884 81885 3754 80 0 0 firewalld Jul 20 11:05:00 someapp kernel: [18130] 0 18130 33359 291 65 0 0 sshd Jul 20 11:05:00 someapp kernel: [18132] 1000 18132 33791 748 64 0 0 sshd Jul 20 11:05:00 someapp kernel: [18133] 1000 18133 28867 122 13 0 0 bash Jul 20 11:05:00 someapp kernel: [18428] 99 18428 208627 42909 151 0 0 node Jul 20 11:05:00 someapp kernel: [18486] 89 18486 22909 250 46 0 0 pickup Jul 20 11:05:00 someapp kernel: [18515] 1000 18515 352905 141851 470 0 0 npm Jul 20 11:05:00 someapp kernel: [18520] 0 18520 33359 291 66 0 0 sshd Jul 20 11:05:00 someapp kernel: [18522] 1000 18522 33359 294 64 0 0 sshd Jul 20 11:05:00 someapp kernel: [18523] 1000 18523 28866 115 12 0 0 bash Jul 20 11:05:00 someapp kernel: Out of memory: Kill process 18515 (npm) score 559 or sacrifice child Jul 20 11:05:00 someapp kernel: Killed process 18515 (npm) total-vm:1411620kB, anon-rss:567404kB, file-rss:0kB

Esto parece un buen artículo sobre el tema: domar al asesino de OOM .

Lo esencial es que Linux supera la memoria. Cuando un proceso solicita más espacio, Linux le dará ese espacio, incluso si es reclamado por otro proceso, bajo el supuesto de que en realidad nadie usa toda la memoria que solicita. El proceso obtendrá el uso exclusivo de la memoria que ha asignado cuando realmente la utiliza, no cuando la solicita. Esto hace que la asignación sea rápida y podría permitirle "engañar" y asignar más memoria de la que realmente tiene. Sin embargo, una vez que los procesos comienzan a usar esta memoria, Linux puede darse cuenta de que ha sido demasiado generoso en la asignación de memoria que no tiene, y tendrá que terminar un proceso para liberar algo. El proceso que debe eliminarse se basa en una puntuación que toma en cuenta el tiempo de ejecución (los procesos de ejecución prolongada son más seguros), el uso de la memoria (los procesos codiciosos son menos seguros) y algunos otros factores, incluido un valor que puede ajustar para reducir el proceso. probablemente sea asesinado. Todo está descrito en el artículo con mucho más detalle.

Edición: Y aquí hay otro artículo que explica bastante bien cómo se elige un proceso (anotado con algunos ejemplos de código de kernel). Lo mejor de esto es que incluye algunos comentarios sobre el razonamiento detrás de las distintas reglas de la badness() .

Hemos tenido problemas recurrentes en Linux en el sitio de un cliente (Red Hat, creo), con OOMKiller (asesino por falta de memoria) eliminando tanto nuestra aplicación principal (es decir, la razón por la que existe el servidor) como sus procesos de base de datos.

En cada caso, OOMKiller simplemente decidió que los procesos estaban usando muchos recursos ... la máquina ni siquiera estaba a punto de fallar por falta de recursos. Ni la aplicación ni su base de datos tienen problemas con las fugas de memoria (o cualquier otra fuga de recursos).

No soy un experto en Linux, pero más bien he recogido su algoritmo para decidir cuándo matar algo y qué matar es complejo. Además, me dijeron (no puedo hablar de la precisión de esto) que OOMKiller está integrado en el Kernel y que simplemente no se puede ejecutar.

Me encontré con este problema últimamente. Finalmente, encontré que mis procesos se eliminaron justo después de que se llamara automáticamente a Opensuse zypper update. Para deshabilitar la actualización de zypper solucioné mi problema.

Si el usuario o sysadmin no eliminó el programa, el kernel puede tener. El núcleo solo mataría un proceso en circunstancias excepcionales, como la falta de recursos extremos (piense en mem + swap agotamiento).

Tratar:

dmesg -T| grep -E -i -B100 ''killed process''

Donde -B100 significa el número de líneas antes de que ocurriera la matanza.

Omitir -T en Mac OS.

Una herramienta como systemtap (o un trazador) puede monitorear la lógica de transmisión de señales del kernel e informar. por ejemplo, https://sourceware.org/systemtap/examples/process/sigmon.stp

# stap .../sigmon.stp -x 31994 SIGKILL SPID SNAME RPID RNAME SIGNUM SIGNAME 5609 bash 31994 find 9 SIGKILL

El filtro de bloqueo en ese script puede ajustarse al gusto o eliminarse para rastrear el tráfico de señales en todo el sistema. Las causas se pueden aislar aún más mediante la recopilación de backtraces (agregar un print_backtrace() y / o print_ubacktrace() a la sonda, para el kernel y el espacio de usuario, respectivamente).