Puede.
Hay dos condiciones diferentes de falta de memoria que puede encontrar en Linux. Lo que encuentre depende del valor de sysctl vm.overcommit_memory (/proc/sys/vm/overcommit_memory )
Introducción:
El núcleo puede realizar lo que se denomina 'sobreasignación de memoria'. Aquí es cuando el kernel asigna a los programas más memoria de la que realmente está presente en el sistema. Esto se hace con la esperanza de que los programas no usen realmente toda la memoria que asignaron, ya que esto es algo bastante común.
overcommit_memory =2
Cuando overcommit_memory está establecido en 2 , el kernel no realiza ninguna sobreasignación en absoluto. En cambio, cuando se asigna memoria a un programa, se garantiza el acceso a esa memoria. Si el sistema no tiene suficiente memoria libre para satisfacer una solicitud de asignación, el kernel simplemente devolverá una falla para la solicitud. Depende del programa manejar la situación con gracia. Si no comprueba que la asignación tuvo éxito cuando realmente falló, la aplicación a menudo encontrará una falla de segmento.
En el caso de la falla de segmento, debería encontrar una línea como esta en la salida de dmesg :
[1962.987529] myapp[3303]: segfault at 0 ip 00400559 sp 5bc7b1b0 error 6 in myapp[400000+1000]
El at 0 significa que la aplicación intentó acceder a un puntero no inicializado, lo que puede ser el resultado de una llamada de asignación de memoria fallida (pero no es la única forma).
overcommit_memory =0 y 1
Cuando overcommit_memory está establecido en 0 o 1 , la sobreasignación está habilitada y los programas pueden asignar más memoria de la que realmente está disponible.
Sin embargo, cuando un programa quiere usar la memoria que se le asignó, pero el kernel descubre que en realidad no tiene suficiente memoria para satisfacerla, necesita recuperar algo de memoria. Primero intenta realizar varias tareas de limpieza de memoria, como como vaciar cachés, pero si esto no es suficiente, terminará un proceso. Esta terminación la realiza el OOM-Killer. El OOM-Killer analiza el sistema para ver qué programas están usando qué memoria, cuánto tiempo han estado ejecutándose, quién los está ejecutando y una serie de otros factores para determinar cuál se elimina.
Una vez que el proceso ha finalizado, la memoria que estaba usando se libera y el programa que acaba de causar la condición de falta de memoria ahora tiene la memoria que necesita.
Sin embargo, incluso en este modo, a los programas aún se les pueden negar las solicitudes de asignación. Cuando overcommit_memory es 0 , el kernel intenta adivinar cuándo debe comenzar a denegar las solicitudes de asignación. Cuando se establece en 1 , no estoy seguro de qué determinación usa para determinar cuándo debe denegar una solicitud, pero puede denegar solicitudes muy grandes.
Puede ver si el OOM-Killer está involucrado mirando la salida de dmesg y encontrar mensajes como:
[11686.043641] Out of memory: Kill process 2603 (flasherav) score 761 or sacrifice child
[11686.043647] Killed process 2603 (flasherav) total-vm:1498536kB, anon-rss:721784kB, file-rss:4228kB
La verdad es que independientemente de la forma en que lo mire, ya sea que su proceso se bloquee debido al administrador de memoria del sistema o a otra cosa, todavía un insecto. ¿Qué pasó con todos esos datos que estabas procesando en la memoria? Debería haberse guardado.
Mientras overcommit_memory= es la forma más general de configurar la administración de Linux OOM, también es ajustable por proceso como:
echo [-+][n] >/proc/$pid/oom_adj
Usando -17 en lo anterior excluirá un proceso de la gestión de memoria insuficiente. Probablemente no sea una gran idea en general, pero si está buscando errores, podría valer la pena, especialmente si desea saber si fue OOM o tu codigo. Incrementar positivamente el número hará que sea más probable que el proceso se elimine en un evento OOM, lo que podría permitirle reforzar mejor la resiliencia de su código en situaciones de poca memoria y garantizar que salga correctamente cuando sea necesario.
Puede verificar la configuración actual del controlador OOM por proceso como:
cat /proc/$pid/oom_score
De lo contrario, podría volverse suicida:
sysctl vm.panic_on_oom=1
sysctl kernel.panic=X
Eso hará que la computadora se reinicie en caso de una condición de falta de memoria. Estableces el X anterior a la cantidad de segundos que desea que la computadora se detenga después de un kernel panic antes de reiniciar. Enloquecer.
Y si, por alguna razón, decides que te gusta, hazlo persistente:
echo "vm.panic_on_oom=1" >> /etc/sysctl.conf
echo "kernel.panic=X" >> /etc/sysctl.conf