Los desarrolladores de Fedora han discutido sobre un tema común que sigue siendo una piedra en el zapato de Linux y es que desde hace mucho tiempo se ha hablado sobre los problemas que llega a presentar Linux al contar con poca memoria en el sistema, lo que lleva al sistema a bloquearse o presentar una bajada en el rendimiento.
Los desarrolladores de Fedora han estado discutiendo formas de evitar las interrupciones de memoria desde el verano de 2019, con el fin de mejorar la experiencia del usuario en el entorno de escritorio. Ante esta situación que se presenta en Fedora, los desarrolladores hablaron y aprobaron la inclusión de Earlyoom en la próxima versión de Fedora que sería la versión Fedora 32.
El grupo de trabajo ha propuesto varias soluciones para congelar el escritorio mientras trabaja, lo que tiene un efecto significativo en la experiencia del usuario. Sin embargo, SIGKIL, que recupera todo el sistema rápidamente y solo finaliza los procesos, se ha propuesto antes, mediante el envío de un SIGTERM para dar instrucciones al final del proceso, puede ser seleccionable apagado por etapas para el usuario.
Sobre EarlyOOM
Earlyoom es un proceso de fondo que se incluirá en Fedora 32 para responder temprano a la falta de memoria en el sistema.
Si la cantidad de memoria disponible es menor que el valor especificado, entonces dependiendo de tamaño de la memoria que queda se enviara Sigterm (memoria libre inferior al 10%) o Sigkill (<5%) que por la fuerza finalizara el proceso que consume la mayor cantidad de memoria.
Aquí se tomara el proceso que tiene el valor más alto /proc/*/oom_score, sin llevar el estado del sistema a borrar los búferes del sistema.
Con ello Earlyoom le permitirá al sistema responder más rápidamente a la falta de memoria sin tener que llamar al controlador OOM (Sin memoria) en el núcleo, que se activa cuando la situación se vuelve crítica y el sistema, como regla ya no responde al usuario.
En otras versiones de Fedora, es posible habilitar el controlador de memoria baja del monitor de memoria baja que utiliza la interfaz /proc/pressure/memory que se introdujo en el kernel de Linux 4.20 y se mejoró en 5.2.
Para evaluar la falta de memoria en el sistema, a diferencia de earlyoom, procesa y envía una notificación a través de DBus sobre la necesidad de reducir el consumo de memoria (si después de esto la situación no ha vuelto a la normalidad, es posible la activación del núcleo OOM Killer ).
El monitor con poca memoria requiere la modificación de las aplicaciones, por lo que se considera como una solución para un futuro lejano, que se puede usar después de la adaptación de las aplicaciones de GNOME.
Para monitorear la situación de memoria insuficiente, las aplicaciones en Glib 2.63.3 agregaron la API GMemoryMonitor, que permite monitorear señales desde un monitor con poca memoria y tomar medidas (por ejemplo, la aplicación puede liberar la memoria utilizada para el almacenamiento en caché, guardar archivos, iniciar la recolección de basura, tratar de reducir la fragmentación de la memoria o completar procesos de soporte inactivos).
El soporte de GMemoryMonitor también se ha agregado a xdg-desktop-portal para su uso en aplicaciones independientes entregadas en formato flatpak.
Finalmente es importante mencionar que la implementación predeterminada de EarlyOOM en Fedora se limita solo a la versión de escritorio por lo que las demás compilaciones de Fedora no contaran con ello.
Como dato adicional, se menciona que EarlyOOM está desarrollado para su uso en el escritorio y parece poco probable que se realicen otras ediciones a menos que aumente la demanda. Actualmente el paquete se encuentra disponible para las diferentes distribuciones de Linux y también los desarrolladores de OpenSUSE están discutiendo sobre su inclusión en el sistema.
Si quieres conocer más al respecto sobre la inclusión de EarlyOOM puedes consultar los siguientes enlaces donde se desarrolla la discusión.
Tambien se puede consultar la documentación e instalación en versiones anteriores de Fedora en el siguiente enlace.
La ñapa de vm.swappiness y vm.dirty_bytes no era suficiente para evitar el bloqueo del escritorio.
¡Muy buena noticia!