aumentar la capacidad de respuesta del escritorio en Linux mientras se intercambia

Todas las distribuciones de GNU / Linux que probé hasta ahora tienen el problema de que cada vez que se llena el ram y el sistema comienza a intercambiarse, todo el escritorio y la interfaz gráfica de usuario dejan de responder hasta el punto de que a veces tengo que esperar unos 5-10 segundos después haber movido el mouse físico hasta que el puntero del mouse se esté moviendo realmente.

Este es un comportamiento molesto, especialmente en sistemas con poca RAM.

¿Hay alguna forma de otorgar a algunas aplicaciones / trabajos, como el entorno de escritorio, etc., una prioridad más alta para permanecer en la memoria RAM que otras aplicaciones, de modo que la aplicación que acapare toda la memoria se intercambie antes que el entorno de escritorio, etc.?

EDITAR: estoy hablando del caso cuando se usa toda la RAM, por lo que siempre comenzará a intercambiarse si no está deshabilitada (no quiero que los procesos se eliminen al azar). Tuve este problema no solo en entornos con poca memoria RAM, sino también con 8GiB de memoria ram en mi máquina de escritorio, en parte debido a muchas máquinas virtuales, en parte debido a la pérdida de memoria. ZRAM tampoco es una solución, ya que solo retrasa el problema. La única solución que se me ocurre para este problema es alguna utilidad de espacio de usuario o API de kernel que permite evitar que se intercambien ciertos trabajos o, al menos, que sea muy poco probable. ¿Alguien conoce otra solución o sabe algo acerca de una herramienta o API que existe o está siendo planificada?

2nd EDIT: ulatencyd no parece funcionar con versiones más recientes de systemd, de acuerdo con https://aur.archlinux.org/packages/ulatencyd-git/ y https://wiki.archlinux.org/index.php/Ulatencyd . Esto puede deberse a que systemd asumió el control total de cgroups desde la perspectiva del espacio de usuario si lo entiendo correctamente.

linux memory freeze swap memory-management FSMaxB
fuente

cgroups, si tiene habilitada la memoria cgroup y la contabilidad de intercambio habilitada ( cgroup_enable=memory swapaccount=1en la línea de comando del kernel; tenga en cuenta que esto tiene un costo de rendimiento menor). Ejemplo de implementación: ulatencyd .

derobert

@derobert Genial, parece que es exactamente lo que estaba buscando. Comenzaré a experimentar con esto tan pronto como tenga tiempo.

FSMaxB

Genial, ulatencyd incluso tiene un paquete AUR, supongo que tengo suerte de ser usuario de Archlinux.

FSMaxB

Incluso hay un artículo wiki wiki.archlinux.org/index.php/Ulatencyd

FSMaxB

¡Si pudiera votar más por esta Q, lo haría! ¿Realmente no hay una forma directa de decirle a la GUI y a algunos programas clave que permanezcan en la RAM para que siga respondiendo? Quiero decir, ¿cuál es el peor de los casos de dar a los usuarios de Linux esta opción? ¿La computadora falla? ¿Quién no ha hecho eso antes? :) Quiero decir, a veces, accidentalmente inicio demasiadas máquinas virtuales porque no pude agregar (números de RAM) correctamente y luego se necesita PARA SIEMPRE para que las cosas vuelvan a estar bajo control. ¡Decirle a la GUI y tal vez al terminal que permanezca en la RAM solucionaría eso, ¿verdad ?! ¡Por favor, alguien conteste esto!

Damon

Respuestas:

Hasta donde sé, este no es un problema específico de Linux, es la forma en que funciona SWAP (o memoria virtual). Si el sistema operativo necesita buscar datos en el disco duro en lugar de la RAM, se ralentizará. Nada de lo que pueda hacer al respecto, acceder al disco es mucho más lento que acceder a la RAM.

No podrá establecer la prioridad con la que se intercambian los procesos, que está determinada por el núcleo que intentará maximizar la eficiencia, no podrá hacerlo mejor. Lo que puede hacer es establecer la prioridad de CPU de un proceso y eso podría ayudar. Su sistema se está reduciendo debido al tiempo que lleva leer / desde SWAP, esto significa que la CPU tendrá que esperar a que el proceso que lo solicita recupere los datos relevantes antes de que pueda continuar. Si configura su DE para que tenga una mayor prioridad para el acceso a la CPU, eso debería llevar sus operaciones a la cima y acelerar un poco las cosas.

Entonces, la prioridad de la CPU se establece con los comandos nicey renice:

 Renice alters the scheduling priority of one or more running processes.
 The following who parameters are interpreted as process ID's, process
 group ID's, or user names.  Renice'ing a process group causes all pro‐
 cesses in the process group to have their scheduling priority altered.
 Renice'ing a user causes all processes owned by the user to have their
 scheduling priority altered.  By default, the processes to be affected
 are specified by their process ID's.

Las prioridades van de -20 (prioridad más alta) a 20 (prioridad más baja). Para cambiar la prioridad de un proceso en ejecución, puede hacer lo siguiente:

renice -15 $PID

dónde $PIDestá el PID del proceso cuya prioridad desea aumentar. Puedes usar pgreppara averiguar cuál es. Por ejemplo:

renice -15 $(pgrep gnome-session)

La otra opción sería establecer la "capacidad de intercambio" del sistema que determina cuándo comenzará a intercambiarse. Un valor de intercambio de 1 significa que solo se intercambiará para evitar errores de falta de memoria. Los valores más altos significan que comenzará a intercambiarse incluso cuando todavía haya memoria física disponible. Puede establecer esto en un valor relativamente bajo para hacer que su sistema cambie lo menos posible. Agregue esta línea a /etc/sysctl.conf:

vm.swappiness=1

CUIDADO: Esa no es una buena idea si no tiene mucha RAM, el intercambio es una buena cosa en general, necesitará jugar un poco con los valores para encontrar el equilibrio adecuado para su sistema.

terdon
fuente

Como usted dice, esto puede resolverse en el espacio del kernel, lo que significa que sería muy específico de Linux. Cambiar el intercambio no cambiará nada porque cuando se usa toda la RAM, el sistema está intercambiando de todos modos. Y afak la prioridad de un proceso no cambiará nada sobre su gestión de memoria, pero solo el comportamiento del programador de CPU y el tiempo de CPU no es realmente útil para acelerar el acceso al disco.

FSMaxB

La prioridad de la CPU @FSMaxB podría ayudar, ya que priorizará el DE, no ayudará si el propio DE está intercambiando, pero lo hará si hay algo más que está deteniendo la CPU y, por lo tanto, ralentizando la máquina.

terdon

Cuando el DE está inactivo durante algún tiempo, en mi experiencia, el DE siempre se intercambia cuando se agota la memoria.

FSMaxB

@FSMaxB sí, eso tiene sentido ya que los DE son cerdos de memoria. Aún así, aumentar su prioridad podría ayudar, al menos el programador no lo retrasará.

terdon