¿Es posible hacer que el asesino OOM intervenga antes?

34

Intento ajustar mi sistema de desarrollo para obtener la máxima fiabilidad. Inhabilité el intercambio, porque para el uso de la GUI hace que la máquina deje de responder de tal manera que ya no se pueda usar. Sin embargo, si las aplicaciones agresivas consumen la memoria, algunos mecanismos parecen ayudar a aprovechar el costo de la velocidad. No hay operación de intercambio de disco duro, pero el sistema no responde de la misma manera. Así que quiero dejar que el asesino de OOM entre en acción antes de que el sistema haga ningún esfuerzo especial en la ganancia de memoria. ¿Es posible configurar el asesino OOM para que actúe si hay menos de 100 MB de memoria física libre, por ejemplo?

linux-kernel memory-management

— Dronus
fuente

2

Creo que el verdadero problema aquí es que no hay suficiente ram para empezar. No utilizará el intercambio a menos que no haya ram. Al desactivar el intercambio ... te quedas sin memoria RAM y no tienes dónde buscarlo. Lo que hace que sucedan cosas feas. Su sistema parece estar mal configurado, y ninguna cantidad de ajustes lo solucionará.

— Journeyman Geek

8

No estoy de acuerdo El desarrollo y el "uso de energía" a menudo implican un uso experimental. Por ejemplo, cuando se utiliza una herramienta de procesamiento de imágenes de línea de comandos, no hay especificaciones sobre la cantidad de memoria que requiere su operación en relación con el tamaño de la imagen. Así que solo lo intento. Y no espero que haga que toda mi máquina sea inútil. Para un solo experimento, podría usar ulimit para mantenerlo seguro, pero para la operación de todo el sistema con muchas veces muchas operaciones, la contención de un proceso no es tan útil, pero definitivamente lo es un 'seguro de vida' para toda la máquina.

— Dronus

1

El hecho de que su sistema se detenga al usar el intercambio es sospechoso. Su computadora está utilizando el intercambio porque no tiene memoria. El intercambio se está ralentizando porque el acceso al disco es lento. El acceso al disco es lento debido a ???. Sus problemas hasta el final. No es solo que tienes poco ram. Es que no puedes usar la única forma de mitigar eso debido a otra cosa.

— Journeyman Geek

77

@JourneymanGeek, estás en el jardín izquierdo. Los discos son lentos en comparación con ram, punto, por lo tanto, el intercambio pesado siempre detiene el sistema. Por supuesto, se quedó sin memoria porque intentó ejecutar un programa que utiliza mucha memoria. La pregunta es qué hacer cuando no hay memoria. Mata al cerdo o disminuye la velocidad debido a que no queda memoria para el caché del disco.

— psusi

2

@TomWijsman, Disk IO es mucho más lento que IO de memoria, por lo que usar el intercambio de discos siempre ha significado una gran desaceleración. A veces (especialmente en los viejos tiempos donde el carnero era costoso y la mayoría de la gente no tenía mucho) eso es preferible a no poder hacer lo que estaba intentando. En estos días, el disco es MUCHO más lento que el RAM, y el RAM es lo suficientemente barato como para que la mayoría de las personas tenga mucho, por lo que en la rara ocasión en que accidentalmente ejecutan algo que usa más RAM del que tienen, a menudo es mejor darse por vencido que tomar 1000 veces tanto tiempo para hacerlo.

— psusi

36

También luché con ese problema. Solo quiero que mi sistema permanezca receptivo, pase lo que pase, y prefiero perder procesos que esperar unos minutos. Parece que no hay forma de lograr esto usando el kernel oom killer.

Sin embargo, en el espacio del usuario, podemos hacer lo que queramos. Así que escribí el Early OOM Daemon ( https://github.com/rfjakob/earlyoom ) que matará el proceso más grande (por RSS) una vez que la RAM disponible sea inferior al 10%.

Sin Earlyoom, ha sido fácil bloquear mi máquina (8 GB de RAM) iniciando http://www.unrealengine.com/html5/ varias veces. Ahora, las pestañas del navegador culpables se matan antes de que las cosas se salgan de control.

— Jakob
fuente

3

¡Gracias por rascarte esta picazón! Amar temprano hasta ahora.

— Thomas Ferris Nicolaisen

1

Acabo de descubrir que Android hace lo mismo durante mucho tiempo. No estoy seguro de si está usando un código personalizado como el suyo para eso.

— Dronus

1

Estoy probando earlyoomahora, funciona bien en una primera prueba de activación. Me pregunto por qué esto no puede implementarse mediante la configuración del kernel o las herramientas del sistema.

— dronus

12

La política predeterminada del núcleo es permitir que las aplicaciones sigan asignando memoria virtual siempre que haya memoria física libre. La memoria física no se usa realmente hasta que las aplicaciones tocan la memoria virtual que asignaron, por lo que una aplicación puede asignar mucha más memoria de la que tiene el sistema, luego comenzar a tocarla más tarde, haciendo que el núcleo se quede sin memoria y active la salida de memoria (OOM) asesino. Sin embargo, antes de que se acabe el proceso de acaparamiento, se ha vaciado el caché del disco, lo que hace que el sistema responda lentamente por un tiempo hasta que el caché se vuelva a llenar.

Puede cambiar la política predeterminada para no permitir la sobrecarga de memoria escribiendo un valor de 2 en /proc/sys/vm/overcommit_memory. El valor predeterminado de /proc/sys/vm/overcommit_ratioes 50, por lo que el núcleo no permitirá que las aplicaciones asignen más del 50% del intercambio ram +. Si no tiene intercambio, entonces el núcleo no permitirá que las aplicaciones asignen más del 50% de su ram, dejando el otro 50% libre para el caché. Eso puede ser un poco excesivo, por lo que es posible que desee aumentar este valor para decir, 85% más o menos, para que las aplicaciones puedan asignar hasta el 85% de su ram, dejando un 15% para el caché.

— psusi
fuente

1

Cambiar estos valores por defecto sin antecedentes teóricos no va a alcanzar en un sistema más confiable, solo puede justificar ese cambio con estadísticas adecuadas. Solo porque puedes cambiarlo no significa que debas hacerlo. Si constantemente está en condiciones de poca memoria, eso significa que está usando más memoria de la que tiene y debe comprar más memoria, no significa que deba manipular sus configuraciones y eliminar aplicaciones aleatorias. Interrumpir con su trabajo diario o introducir corrupción, ese no es el camino a seguir ...

— Tamara Wijsman

3

@TomWijsman, la pregunta deja en claro que no está constantemente en condiciones de poca memoria; él solo a veces ejecuta un comando que toma una cantidad inesperadamente grande de memoria. Comprar más memoria no es la única solución cuando se te acaba. Otras posibles soluciones incluyen encontrar mejores formas de hacer uso de la memoria que tiene, o simplemente no hacer lo que necesite tanta memoria. La pregunta deja en claro que esto último es más aceptable que salir y comprar más carnero.

— psusi

¿Qué línea en la pregunta lo aclara? Veo lo contrario dado en I disabled swap, because for GUI usage it mostly renders the machine unresponsive in such a way not useable anymore.. Mencionó la GUI, mientras asumes que ejecuta un comando. Comprar más memoria es la primera solución, usar menos memoria usted mismo es la segunda solución, hacer que su sistema sea inestable al jugar con los valores predeterminados estables es la última solución. La pregunta no tiene que ser respondida literalmente, por lo que no veo cuál es su problema que tienen que molestarnos a los dos en los comentarios. Rant no ayuda ...

— Tamara Wijsman

44

Oye, esta respuesta sonaba genial. Desafortunadamente, el 'commit' se refiere a la demanda de memoria virtual que parece, lo cual es bastante mal estimado por los programadores de aplicaciones. Por ejemplo, con mi escritorio (sin intercambio) ejecutándose, se utilizan alrededor de 400 de 2000mb de memoria física, pero 1600mb se 'compromete /proc/meminfo' como Committed_ASestado. Con algunas aplicaciones ejecutándose, este valor excede fácilmente la memoria física, por lo que es difícil establecer un límite factible con esto.

— Dronus

3

¡Guarda tu trabajo antes de intentar esto! : PI tuvo fallas inmediatas de todo (bash, gestor de ventanas, etc.).

— jozxyqk

8

Para mí, configurar vm.admin_reserve_kbytes = 262144 hace exactamente esto. El asesino OOM interviene antes de que el sistema deje de responder por completo.

— Michael Vigovsky
fuente

1

Me gusta la idea, pero ¿significa que tiene 256MiB de memoria física nunca utilizada?

— Jérôme Pouiller

1

256MiB se utilizarán para cachés. Los cachés son realmente importantes, no se trata solo de correr más rápido, el sistema no funcionaría si no hay suficiente memoria para los cachés. El código de cada programa en ejecución se puede descargar de la memoria porque está mapeado y se puede volver a leer desde el disco. Sin cachés, cada cambio de tarea requerirá la lectura del disco y el sistema dejará de responder por completo.

— Michael Vigovsky

4

Las otras respuestas tienen buenas soluciones automáticas, pero creo que puede ser útil también habilitar la SysRqclave para cuando las cosas se salgan de control. Con la SysRqclave, estaría enviando mensajes manualmente al núcleo, y puede hacer cosas como reiniciar de forma segura (con SysRQ + REISUB) incluso si el espacio de usuario se ha congelado por completo.

Para permitir que el núcleo escuche solicitudes, configure kernel.sysrq = 1o habilite solo las funciones que probablemente usará con una máscara de bits (documentado aquí ). Por ejemplo kernel.sysrq = 244, habilitará todos los combos necesarios para el reinicio seguro anterior, así como la invocación manual del asesino OOM con SysRq + F.

— timuzhti
fuente

-2

La fiabilidad no se alcanza con condiciones de poca memoria y un asesino OOM.

Está mal organizar una fiesta en un armario y colocar "limpiar mi armario" en tu pequeña lista de reproducción.

¿Es posible hacer que el asesino OOM intervenga antes?

Hacer esto tendrá resultados secundarios no deseados, ya que no tienes control sobre lo que se mata.

Intento ajustar mi sistema de desarrollo para obtener la máxima fiabilidad.

La confiabilidad máxima implica probar su sistema y mejorar su sistema basado en estas pruebas.

Simplemente ajustar cosas al azar no te llevará a ninguna parte ...

Inhabilité el intercambio, porque para el uso de la GUI hace que la máquina deje de responder de tal manera que ya no se pueda usar. Sin embargo, si las aplicaciones agresivas consumen la memoria, algunos mecanismos parecen ayudar a aprovechar el costo de la velocidad.

Debido a las condiciones de poca memoria, deshabilitar el intercambio no mejorará el comportamiento , hace lo contrario .

Para aumentar la confiabilidad en esta situación, agregue más memoria de manera que su sistema responda mejor y no se eliminen procesos aleatorios sin la intención del usuario. No debe recurrir a condiciones de poca memoria y un mecanismo como este, especialmente no en un entorno de desarrollo ...

No hay operación de intercambio de disco duro, pero el sistema no responde de la misma manera.

Las condiciones de poca memoria resultan en la falta de respuesta, ya sea que tenga un intercambio o no.

Así que quiero dejar que el asesino de OOM entre en acción antes de que el sistema haga ningún esfuerzo especial en la ganancia de memoria.

Esfuerzos especiales que harán más daño que bien, como expliqué anteriormente. En cambio, podría matar procesos que no necesita, pero supongo que no puede hacerlo, por lo que la OOM matará los procesos que necesita.

¿Es posible configurar el asesino OOM para que actúe si hay menos de 100 MB de memoria física libre, por ejemplo?

Puede ser, pero obtienes un mayor retorno de la inversión si solo compras un poco de memoria extra que realmente no cuesta mucho en estos días. Tenga en cuenta que a la larga se va a golpear en el pie si continúa trabajando en condiciones de poca memoria. OOM es como un agente judicial, no te ayuda, ayuda al sistema operativo ...

— Tamara Wijsman
fuente

77

Por supuesto, deshabilitar el intercambio mejora el comportamiento porque, en lugar de destruir el disco, el OOM se activa y mata al cerdo de la memoria. Quedarse sin ram no es el problema (y agregar más solo significa que debe esforzarse más para quedarse sin ram). El problema es qué hacer cuando se te acaba. Desea que el OOM mate al cerdo y, por lo tanto, alivie la condición de poca memoria.

— psusi

77

Porque matar una aplicación que está tratando de usar más memoria de la que tienes es preferible a poner de rodillas a todo el sistema. En un mundo perfecto, tendría memoria ilimitada y nunca se agotaría, pero en realidad, a veces se agota por accidente y preferiría que se le diga "no hay suficiente memoria" en lugar de detener el sistema.

— psusi

55

Comprar memoria adicional puede resolver algunos problemas, dependiendo de la cantidad comprada. Pero no cambia el hecho de que puede haber usos inesperados por órdenes de magnitud. Entonces, quiero que la aplicación falle, pero NO el sistema en esas condiciones. Algunos ejemplos: Procese una carpeta llena de imágenes comprimidas, la mayoría de ellas de tamaño "normal", pero algunas de ellas realmente grandes. Un pequeño error podría hacer un bucle muerto con memoria desbocada comiendo 1GB / s. Abra accidentalmente un archivo de video en un editor de texto. Por lo general, esto termina con síntomas como ratón desigual y la interfaz de usuario casi muerto hasta que las patadas en OOM.

— dronus

66

@TomWijsman también hay bucles casi muertos, ya que hay algoritmos que se comportan lineales en el caso medio pero exponenciales en el peor de los casos, dependiendo de los datos de entrada. Y no puedo enviar una señal de apagado si el mouse es desigual y los clics, así como la entrada del teclado muestra una latencia de un minuto. Por lo general, cambio a un terminal de modo de texto y espero minutos para que el inicio de sesión continúe solo para emitir un killtipeo a ciegas.

— Dronus

66

Tampoco tengo problemas para matar aplicaciones que se ejecutarían sin funcionar. Considere un sistema con 2GB físico + 2GB de intercambio. Una aplicación que agota rápidamente la memoria física también puede comer fácilmente el intercambio. Simplemente moriría más tarde, después de que el sistema no respondiera durante minutos u horas. Entonces, ¿por qué no matarlo rápidamente antes de que la operación de la GUI se vuelva escamosa? Muchos procesos hacen todo su trabajo con 10 mb, algunos toman 1 gb y otros raros necesitarían 10 gb, así es la vida.

— Dronus