¿Cuál es el mejor dirty_background_ratio y dirty_ratio para mi uso?

¿Cuál es el mejor dirty_background_ratio y dirty_ratio para mi uso?

Así que estoy jugando dirty_background_ratio and dirty_ratioy espero encontrar los parámetros correctos con su ayuda profesional.

Por ahora estoy usando:

vm.dirty_background_ratio = 20 vm.dirty_ratio = 60

El uso principal es el de torrents, lo que significa que los archivos se descargarán a través del cliente de torrent y luego se transmitirán. Posibilidad de realizar muchas descargas a la vez, por eso debería utilizar el almacenamiento en caché de RAM, pensando en los valores correctos.

¿Quizás podrías sugerirme los valores correctos?

Respuesta1

Tu idea y los valores (aproximadamente duplicarlos) me parecen bien, pero no explicaste qué quieres decir exactamente con RAM.almacenamiento en caché. Aquí es más simplemente unalmacenamiento en búferporque todas las páginas sucias se dirigen al disco sin modificar.

Si tiene muchas IO en el mismo dispositivo de bloque, colisionará un poco más tarde. La cantidad de páginas sucias no es el único factor desencadenante, también existe (mm/página-escritura.c):

/*
 * The longest time for which data is allowed to remain dirty
 */
unsigned int dirty_expire_interval = 30 * 100; /* centiseconds */

Lo que da los 30 s predeterminados. Esto podría ser suficiente. Pero significa que las páginas sucias anteriores a esa edad no se retendrán (dimensión temporal del almacenamiento en búfer/caché).

Y si tiene IO concurrente, estas configuraciones globales también lo afectarán.


La mejor explicación pararelación_suciayrelación_fondo_sucioestá en el mismo archivo:

/* The following parameters are exported via /proc/sys/vm */

/*
 * Start background writeback (via writeback threads) at this percentage
 */
int dirty_background_ratio = 10;
...
/*
 * The generator of dirty data starts writeback at this percentage
 */
int vm_dirty_ratio = 20;

Muestra que es lo mismo desde diferentes lados (sucio ahora, limpio después).


A continuación se muestran algunos comandos con los que analizar páginas sucias:

]# cp MAINTAINERS MAINTAINERS-2

]# grep dirty /proc/vmstat 
nr_dirty 135
nr_dirty_threshold 311361
nr_dirty_background_threshold 155490

Los valores de umbral se calculan a partir de los valores de relación (dados como porcentaje o bytes). Tengo 8 GB = 2 millones de páginas, por lo que este es el 10 % y el 20 %, respectivamente.


Con la herramienta de tipos de páginas puedes identificar estas páginas sucias con mayor precisión. Esto lee /proc/kpageflags y tarda aproximadamente 200 ms.

]# ./tools/vm/page-types  -b dirty -b lru -b ~active,~reclaim,~mmap |cut -c-80
             flags      page-count       MB  symbolic-flags                     long-symbolic-flags
0x0000000000000030               1        0  ____Dl__________________________________
0x0000000000000038             130        0  ___UDl__________________________________
0x0000000000044038               1        0  ___UDl________b___u_____________________
0x000000000000403c              23        0  __RUDl________b_________________________
             total             155        0

No importa si me siento y espero (durante 30 segundos) o manualmente sync, las páginas sucias pronto desaparecen.

]# sync
]# grep dirty /proc/vmstat 
nr_dirty 0
...

Y las 130 páginas completas de "UDl" han desaparecido, es decir. los que están "actualizados, sucios, en la lista LRU".

]# ./tools/vm/page-types  -b dirty -b lru -b ~active,~reclaim,~mmap |cut -c-80
             flags      page-count       MB  symbolic-flags                     long-symbolic-flags
0x0000000000044038               1        0  ___UDl________b___u_____________________
0x000000000000403c              23        0  __RUDl________b_________________________
             total              24        0

Estas 130 + 1 páginas de diferencia en dos líneas son exactamente el tamaño del archivo:

]# ls --block-size=4096 -s MAINTAINERS 
131 MAINTAINERS

Estos son mis consejos profesionales para jugar.

información relacionada