Por lo que entiendo, cuando el sistema está cerca de no tener memoria libre, el kernel debería comenzar a matar procesos para recuperar algo de memoria. Pero en mi sistema esto no sucede en absoluto.
Supongamos un script simple que solo asigna mucha más memoria que la disponible en el sistema (una matriz con millones de cadenas, por ejemplo). Si ejecuto un script como este (como usuario normal), solo obtiene toda la memoria hasta que el sistema se congela por completo (solo funciona SysRQ REISUB).
La parte extraña aquí es que cuando la computadora se congela, el LED del disco duro se enciende y permanece así hasta que la computadora se reinicia, ¡ya sea que tenga una partición de intercambio montada o no!
Entonces mis preguntas son:
- ¿Es este comportamiento normal? Es extraño que una aplicación ejecutada como un usuario normal pueda bloquear el sistema de esta manera ...
- ¿Hay alguna manera de hacer que Ubuntu simplemente elimine automáticamente esas aplicaciones cuando tienen demasiada (o la mayoría) memoria?
Información Adicional
- Ubuntu 12.04.3
- Kernel 3.5.0-44
RAM: ~ 3.7GB de 4GB (compartido con la tarjeta gráfica). * *
$ tail -n+1 /proc/sys/vm/overcommit_* ==> /proc/sys/vm/overcommit_memory <== 0 ==> /proc/sys/vm/overcommit_ratio <== 50 $ cat /proc/swaps Filename Type Size Used Priority /dev/dm-1 partition 4194300 344696 -1
tail -n+1 /proc/sys/vm/overcommit_*
y agrega la salida. Vea aquí también: ¿Cómo configuro oom-killer?Allocation failed
). Pero sin intercambio simplemente congela la computadora. ¿Se supone que funciona de esta manera (solo matar cuando se usa el intercambio)?Respuestas:
De la documentación oficial
/proc/sys/vm/*
:Con el fin de resumir, al establecer
oom_kill_allocating_task
que1
, en lugar de escanear el sistema en busca de procesos para matar, que es una tarea costosa y lenta, el kernel simplemente matar el proceso que hizo que el sistema salga de memoria.Según mis propias experiencias, cuando se activa un OOM, el núcleo no tiene más "fuerza" suficiente para realizar dicho análisis, lo que hace que el sistema sea totalmente inutilizable.
Además, sería más obvio simplemente matar la tarea que causó el problema, por lo que no entiendo por qué está configurado
0
de forma predeterminada.Para la prueba, puede escribir en el pseudo-archivo adecuado
/proc/sys/vm/
, que se deshará en el próximo reinicio:Para una solución permanente, escriba lo siguiente en
/etc/sysctl.conf
un nuevo archivo/etc/sysctl.d/
, con una.conf
extensión (/etc/sysctl.d/local.conf
por ejemplo):fuente
0
de forma predeterminada". - porque el proceso que solicitó memoria no es necesariamente el que "causó el problema". Si el proceso A acapara el 99% de la memoria del sistema, pero el proceso B, que utiliza el 0,9%, es el que desencadena el asesino OOM por mala suerte, B no "causó el problema" y no tiene sentido matar B. Tener eso, ya que la política corre el riesgo de que los procesos de baja memoria totalmente sin problemas sean eliminados por casualidad debido al uso de memoria desbocada de un proceso diferente .vm.admin_reserve_kbytes
se incrementa a, digamos, 128 MB . La configuraciónvm.oom_kill_allocating_task = 1
parece aliviar el problema, realmente no lo resuelve (y Ubuntu ya se ocupa de las bombas de horquilla por defecto).sudo sysctl -w vm.oom_kill_allocating_task=1
Actualización: el error está solucionado.
La respuesta de Teresa es suficiente para solucionar el problema y es buena.
Además, he presentado un informe de error porque definitivamente es un comportamiento roto.
fuente
Puede probar earlyoom , un asesino OOM que opera en el espacio del usuario e intenta matar el proceso más grande en una situación OOM.
fuente
En primer lugar, recomiendo la actualización a 13.10 (instalación limpia, guarde sus datos).
Si no desea actualizar, cambie vm.swappiness a 10 y si encuentra problemas con su ram, instale zRAM.
fuente
vm.swappiness
hace más daño que bien, incluso más en sistemas que sufren problemas de poca memoria.