¿Cuál es el valor apropiado de vm.swappiness cuando se usa zram?

Estoy usando zram en mi computadora como un intercambio comprimido respaldado por RAM. Cuando el sistema necesita intercambiar algo, cambiarlo a un archivo de intercambio respaldado por zram es más o menos equivalente a comprimir esos datos en la memoria para liberar espacio. Esto hace que el intercambio sea muy rápido la mayor parte del tiempo, en relación con el intercambio respaldado por disco. Debido a esto, me pregunto si se puede obtener algún rendimiento al alentar al sistema a cambiar las cosas no utilizadas de manera más agresiva, ya que puede hacerlo sin golpear realmente el disco.

Entonces, ¿alguien ha jugado con, digamos, establecer vm.swappiness100 mientras usa zram? ¿Sería esto deseable?

sysctl -w vm.swappiness=100

memory linux-kernel swap ram zram Ryan C. Thompson
fuente

Esta es una excelente pregunta y creo que algunos puntos de referencia son para eliminar las opiniones y llegar a los hechos ...

Elder Geek

Buena idea, y zram podría haber mejorado desde 2012 cuando lo usé por última vez :-)

Huygens

Hice una pequeña prueba y, por lo que puedo decir, la memoria "reservada" para zram todavía se usa como caché. Si esto se confirma, ¿creo que podría tener sentido mantener el intercambio bajo para evitar ciclos de CPU?

Vitor

Respuestas:

Realmente no recomendaría poner el intercambio más alto. Un mecanismo común en el núcleo es que colocará páginas (trozos de memoria) en el intercambio para liberar algo de memoria para otras tareas en ejecución.

Primer "problema" cuando el núcleo quiere que se liberen n páginas, m (con m <n, m es el número de páginas comprimidas requeridas para contener n) se crean nuevamente en la RAM, no estoy seguro de si eso puede perturbar el núcleo o no.

De todos modos, cuando tenga páginas en el intercambio, es posible que use la aplicación más adelante con algunas de sus páginas en el intercambio. Lo que hace el kernel es recuperar esas páginas en la memoria física, pero no las elimina del intercambio (que con el intercambio estándar puede verse como almacenamiento en caché , por lo que cuando la aplicación vuelve en segundo plano, el kernel no tiene que volver a escribir esas páginas en el intercambio lento). Sin embargo, con zram quizás no sea un truco sabio, ¡porque entonces tienes en memoria las m páginas en zram + las n páginas que están de vuelta en la memoria!

El núcleo tiene normalmente una "memoria total" que puede usar para hacer sus negocios. Cuando agrega zram, solo cuenta en la memoria de "intercambio", como lo haría con cualquier intercambio basado en disco, pero reduce la "memoria total" real y eso no es esperado / anticipado por el núcleo. ¡A veces puedes tener un comportamiento extraño y no deseado debido a esto!

Con zram, sería bueno que el núcleo no cambie demasiado a esta área cuando está bajo presión de memoria. ¡Y siempre debe tener una partición de intercambio de disco duro real más grande que al menos el tamaño máximo de su zram, de modo que el sistema no obtenga OOM mientras que al mismo tiempo verá mucho espacio libre según lo informado por free!

Huygens
fuente

zram proporciona dispositivos de bloqueo de RAM. Todo lo escrito en estos dispositivos de bloque se comprime. Si los dispositivos de bloque zram se usan como intercambio, cuando el sistema intenta mover partes de la memoria para intercambiar, efectivamente moverá la memoria de una parte de la RAM a otra, excepto que los datos se comprimirán antes de copiarse en el destino. Esto funciona efectivamente como un mecanismo de compresión de memoria barato para mejorar la capacidad de respuesta en sistemas con cantidades limitadas de memoria. ... Zram ha estado en escena desde Linux 2.6.33. En 3.14, zram se trasladó de la puesta en escena a drivers / block / zram.

Élder Geek

@ElderGeek exactamente! Y tomaré un ejemplo para ilustrar por qué eso no es perfecto. El kernel intentará eliminar 64 MB de RAM, los colocará en el intercambio de zram. El trozo comprimido de 64 MB ahora es de 32 MB. El resultado es que la memoria disminuyó en 32 MB y no en 64 MB. Ahora, qué sucede cuando la aplicación requiere los 64 MB de nuevo en la memoria, el núcleo copia (y no mueve) el fragmento de nuevo en la memoria. Ahora tiene 64 MB en RAM + 32 MB en zram. ¿Por qué copiar? Porque el núcleo almacena en caché las páginas como expliqué en mi respuesta. Ambos comportamientos no son ideales. Y cuando la memoria no es bien comprimible, eso es aún peor.

Huygens

Aún en la fase de prueba. Creo que debe haber alguna forma de ajustar el algoritmo de almacenamiento en caché que usa zram para liberar la página comprimida cuando se vuelve a copiar en la RAM sin comprimir.

Élder Geek

Lo intenté varias veces hasta 2012. En ese momento, mi computadora estaba limitada a 1 GB de RAM y mientras navegaba por Internet era muy lenta (generalmente tengo 10-50 pestañas abiertas). Pero desde entonces nunca lo volví a usar. Tengo más que suficiente RAM que ya no uso swap. Cuando usé zram con Firefox en ese entonces, rápidamente comencé a "intercambiar" dada la poca RAM que tenía. Y rápidamente tuve un sistema que no responde con muchos bloqueos. Sin zram fue dolorosamente lento pero estable al menos. Mi problema era que probablemente estaba comprimiendo / descomprimiendo constantemente las páginas de memoria.

Huygens

Sí, mis resultados han sido algo similares, en un sistema con 8 GB pude forzar un OOM al lanzar varias máquinas virtuales durante un trabajo de codificación. ¿Tienes alguna experiencia con zswap? Parece una alternativa viable basada en lo que he leído.

Élder Geek

Respuesta corta: vm.swappiness=100es el valor apropiado para zram (al menos en Debian Stretch con Linux 4.9, creo que es el mejor valor)

Ya lo pruebo vm.swappiness=100por mí.

Creo que puede hacer una prueba simple para asegurarse de qué valor es mejor para usted.

También hice otro programa simple para probar esta pregunta. x En mi máquina, un vm.swappinessvalor muy bajo (como vm.swappiness=1) causará un problema obvio de respuesta.

Sobre SwapCacheden /proc/meminfo:

Primero, intente vm.page-cluster=0, esto tal vez pueda reducir algunos inútiles SwapCacheddel intercambio.

SwapCached puede acelerar zram igual que el dispositivo de intercambio no zram

SwapCached Se puede reutilizar (gratis) cuando sea necesario:

./linux-4.9/mm$ grep -rn delete_from_swap_cache
memory-failure.c:715:   delete_from_swap_cache(p);
shmem.c:1115:       delete_from_swap_cache(*pagep);
shmem.c:1645:            * unaccounting, now delete_from_swap_cache() will do
shmem.c:1652:               delete_from_swap_cache(page);
shmem.c:1668:       delete_from_swap_cache(page);
vmscan.c:673:       __delete_from_swap_cache(page);
swap_state.c:137:void __delete_from_swap_cache(struct page *page)
swap_state.c:218:void delete_from_swap_cache(struct page *page)
swap_state.c:227:   __delete_from_swap_cache(page);
swapfile.c:947:         delete_from_swap_cache(page);
swapfile.c:987: delete_from_swap_cache(page);
swapfile.c:1023:            delete_from_swap_cache(page);
swapfile.c:1571:            delete_from_swap_cache(page);
./linux-4.9/mm$

analfabeto
fuente

Las páginas deben intercambiarse (en el disco) cuando la memoria está llena. Si está utilizando la memoria para crear el lugar para intercambiar páginas cuando la memoria está llena, uno pensaría que supera el propósito, excepto si la compresión marca la diferencia (y luego sería natural comprimir la memoria directamente en lugar de pasar por intercambiar). Supongo que uno tendría que comparar esto, ya que las computadoras son cada vez más rápidas en la compresión y descompresión en comparación con la velocidad de la memoria.

Alejandro
fuente

He descubierto que el intercambio respaldado por zram es bastante útil cuando el sistema se está quedando sin memoria. Me ha salvado varias veces de quedarme completamente atascado en el infierno de intercambio y tener que reiniciar (estoy analizando grandes conjuntos de datos, por lo que necesito la memoria, todos los 24 GB). Me pregunto si el vm.swappinessvalor está ajustado para el intercambio respaldado por disco y si debería cambiarlo si usaré principalmente el intercambio respaldado por zram.

Ryan C. Thompson

"cada vez más rápido"? En la compresión mosca ha estado llevando a cabo mejor que el disco E / S directa por más de la última década (su nunca va a ser más rápido que el acceso a la memoria - que no es el punto)

symcbean

symcbean, olvidaste "en comparación con la velocidad de la memoria". ¿Dónde está el desacuerdo?

Alexander

Creo que el punto de symcbean es que el objetivo de las páginas con respaldo de memoria comprimida (zram) es reemplazar el intercambio al medio físico. La razón por la que no es "natural comprimir la memoria directamente" es porque sería complicado para las aplicaciones tener que determinar qué partes de su memoria podrían comprimirse y cuándo; El subsistema VM es un lugar mucho más fácil para implementar esto. Las cargas de trabajo que se benefician de zram tienen páginas que no están en el conjunto de trabajo y se pueden comprimir fácilmente.

Daniel Papasian