El sistema se cuelga cuando se queda sin memoria

34

Tengo un eeePC 900a: tiene un flash de 8GB como disco y solo 1GB de RAM. La distribución de Linux instalada en él es ArchLinux.

Cuando el sistema se queda sin memoria, deja de responder: lleva varios segundos / minutos hacer cosas como cambiar a TTY1 o incluso mover el puntero del mouse. A veces parece que el sistema se congela: hace tres años, lo dejé solo y nada ha cambiado hasta ahora.

Prefiero evitar crear una partición / archivo de intercambio en este eeePC ya que el disco ya es tan pequeño, y también porque las muchas escrituras en el espacio de intercambio acortarían mucho la vida útil de la tarjeta flash. Además, creo que un archivo / partición de intercambio simplemente movería el problema, en lugar de solucionarlo definitivamente.

¿No se supone que el núcleo mata algunas aplicaciones aleatorias cuando se queda sin memoria? ¿Por qué falla (o tarda años) en hacer eso?

Hace unos meses / años ya intenté profundizar en esto, pero no pude encontrar nada que realmente funcionara ...

linux memory freeze

— peoro
fuente

1

¿Qué DE / WM estás utilizando en tu configuración, qué servicios / demonios estás ejecutando? El uso de un entorno de escritorio lleno de fletches y la navegación con Chromium o Firefox, por ejemplo, comen su RAM para el brunch. 1 GB de RAM debería ser suficiente para ejecutar Arch Linux, pero lo que realmente importa es lo que pones encima.

1

Estoy usando LXDE. Chromium es el programa que generalmente toma la mayor parte de la RAM. De todos modos, este no es el punto. No soy yo quien debe preocuparse por la cantidad de memoria que usa mi sistema, es mi sistema quien no debería morir por eso. Si mi sistema se está quedando sin memoria, es gratis matar cualquier aplicación que desee, ¡solo quiero que no se congele !

— peoro

66

Es decir, yo estoy pensando seriamente en la ejecución de un script como el siguiente (en pseudocódigo): while(true){ if( $FREE_MEMORY<10MB ){ kill -9 $RANDOM_PID; } }. Esto definitivamente solucionaría mi problema. Pero espera, ¿no se supone que el kernel haga eso (y de una manera mucho mejor que mi script)? ¿Por qué no está haciendo su trabajo?

— peoro

2

@ Marcin, eso solo movería el problema, no lo solucionará. Incluso si tuviera 4 GB de memoria (gracias a algunos cambios), mi sistema podría quedarse sin memoria (colgándose así). Lo que quiero evitar es que mi sistema se congele cuando no tiene RAM. Si mi núcleo de repente acabara con el cromo tan pronto como mi RAM termine, estaría feliz incluso con el 1GB que tengo ahora.

— peoro

44

@Lee El "magic sysrq" es una combinación de teclas que va directamente al kernel. Esto a menudo funcionará incluso si el teclado y el mouse no responden. Ver en.wikipedia.org/wiki/Magic_SysRq_key

— Raman

14

Es posible llamar a OOM-killer (asesino sin memoria) directamente por combinación de teclado:

SysRq-F

La tecla SysRq generalmente se combina dentro de la tecla PrtSc en los teclados.

OOM-killer mata algunos procesos (-es) y el sistema vuelve a responder.

Thx Raman por consejos sobre esta característica en los comentarios anteriores.

PD: Esto me ayudó mucho. Estoy de acuerdo con la opinión de que este es el consejo más útil sobre ese problema si es causado por Chrome o cualquier software codicioso de memoria. Pero debe tener en cuenta que OOM-killer podría matar algún proceso realmente importante, úselo con cuidado.

— Arkemlar
fuente

2

Tengo la llave PrtScn|SysRq. Pero al presionar SysRq - Fsolo se obtiene una captura de pantalla

— Lee

2

Dado que básicamente tomaste mi comentario anterior y lo respondiste, una pequeña atribución hubiera sido agradable. Te voté de todos modos. :-)

— Raman

3

@Lee Tienes que habilitarlo. Algunas distribuciones no tienen el sistema mágico habilitado por defecto. Esto debería ayudar: google.ca/search?q=sysrq+enable

— Raman

2

@Raman Apuesto al 99% que encuentra que esto no puede "habilitarlo" de forma predeterminada porque su máquina ya está congelada ... ¿por qué no está habilitada de forma predeterminada?

— themihai

3

@themihai porque muchas personas lo consideran un riesgo de seguridad: le da acceso directo al núcleo a través del acceso físico a un dispositivo de entrada, independientemente del estado de la aplicación, por ejemplo, pantallas de bloqueo y demás.

— Raman el

12

El estado natural de las cosas es que los datos de la aplicación están en la RAM y los archivos están en el disco.
El estado ideal de las cosas, en cuanto al rendimiento, es que los datos de uso frecuente están en la RAM, y los datos que no se necesitan en este momento están en el disco.
En un sistema normal, el núcleo hace dos cosas para intentar alcanzar este ideal:

Los datos de la aplicación que no se han utilizado durante un tiempo se pueden mover al disco: esto es intercambio.
Los datos de los archivos que se han utilizado recientemente se guardan en la RAM: esta es la memoria caché del disco (para los datos leídos desde el disco) y las memorias intermedias del disco (para los datos que están a punto de escribirse en el disco).

En un sistema típico, una parte importante de la RAM se dedica a la memoria caché y los búferes (el 50% es una cifra típica). Dado que la RAM es un recurso finito, esto puede requerir el desplazamiento de algunos datos de la aplicación para intercambiar (el intercambio solo es necesario si hay una mejor manera de usar la RAM).

En un sistema sin intercambio, hay un punto en el que los datos de la aplicación utilizan casi toda la RAM, por lo que apenas queda espacio para la memoria caché. Entonces es probable que el sistema sea lento. El núcleo no comenzará a matar aplicaciones hasta que realmente tenga que hacerlo. Mientras las aplicaciones solo llenen el 99% de la memoria disponible, el sistema sigue funcionando, pero muy lentamente porque los datos de los archivos deben cargarse y recargarse desde el disco todo el tiempo. Con las mismas aplicaciones ejecutándose, el sistema sería más rápido con el intercambio en ese punto.

Para más información sobre este tema, vea esta discusión de lkml y esta publicación de blog .

No conozco una forma directa de decirle al kernel que reserve una cantidad mínima de RAM para el caché del disco. Podría configurar una pequeña parte de su RAM como espacio de intercambio , tal vez incluso comprimido . Hay informes de éxito en ese frente , aunque no garantizo su caso particular.

— Gilles 'SO- deja de ser malvado'
fuente

1

Gracias por la explicación y los enlaces, ayudaron a despejar algunas dudas sobre el intercambio. Siguiendo la respuesta de @Marcin a mi pregunta, configuré 256MB de intercambio virtual comprimido (compcache) en mi RAM. Sin embargo, esto no responde completamente a mi pregunta: entiendo que mi sistema será lento cuando la aplicación use toda la RAM y no se almacene nada en caché; Aún así, no puedo entender por qué este sistema se cuelga durante minutos / horas (¿tal vez para siempre?) Cuando estoy completamente sin RAM. Creo que mi kernel no está haciendo su trabajo para eliminar aplicaciones cuando no hay memoria, si 3 horas no son suficientes para cambiar a TTY1.

— peoro

He desactivado el intercambio con 32 GB de memoria física y cuando el software defectuoso se escapa con la asignación de memoria (hola ld, pedazo de basura), todavía se cuelga durante casi un minuto, despertando lo suficiente como para permitirme mover el mouse increíblemente lento por un segundo o dos cada varios segundos. El manejo de OOM de Linux es una completa basura. Si tengo suerte, el asesino OOM mata el proceso correcto sin arruinar el entorno de escritorio por completo. Y soy un gran admirador de Linux. Es mucho peor con la paginación habilitada. La paginación de Linux es una broma.

— doug65536

6

Este es un error conocido desde 2007: consulte Congelación del sistema en uso de memoria alta .

En esta situación, Windows muestra un cuadro de diálogo que advierte al usuario que cierre una o más aplicaciones.

— Dan Dascalescu
fuente

2

Parece estar "Sin asignar" en Ubuntu. ¿Quizás el DE debería advertir al usuario o incluso congelar la aplicación de uso intensivo de memoria?

— nkkollaw

1

@nbrogi: cualquier cosa menos congelar en silencio. Pero buena suerte para convencer a los desarrolladores de Ubuntu de que hagan eso.

— Dan Dascalescu

6

Recientemente encontré una solución a mi problema.

Como el asesino OOM de Linux no puede hacer su trabajo correctamente, comencé a usar un asesino OOM del espacio de usuario: earlyoom . Está escrito en C, bastante configurable y funciona a las mil maravillas.

También escuché sobre algunas alternativas, como la OOMD de Facebook , desarrollada para ejecutarse en sus servidores, pero no he probado esta.

— peoro
fuente