La traducción del artículo se preparó la víspera del inicio del curso. .
Periódicamente, aquí y allá, surgen preguntas sobre las recomendaciones de Gluster con respecto al ajuste del kernel y si es necesario hacerlo.
Tal necesidad rara vez surge. En la mayoría de las cargas de trabajo, el kernel funciona muy bien. Aunque hay un inconveniente. Históricamente, el kernel de Linux ha estado dispuesto a consumir mucha memoria si se le da la oportunidad, incluso para el almacenamiento en caché como la forma principal de mejorar el rendimiento.
En la mayoría de los casos, esto funciona bien, pero bajo una carga pesada puede causar problemas.
Tenemos mucha experiencia con sistemas intensivos en memoria como CAD, EDA y similares, que comenzaron a ralentizarse bajo una gran carga. Y a veces nos encontramos con problemas en Gluster. Después de observar cuidadosamente el uso de la memoria y la latencia del disco durante muchos días, obtuvimos su sobrecarga, gran iowait, errores del kernel (kernel oops), bloqueos, etc.
Este artículo es el resultado de muchos experimentos de ajuste realizados en diversas situaciones. Gracias a estos parámetros, no solo ha mejorado la capacidad de respuesta general, sino que el clúster también se ha estabilizado significativamente.
Cuando se trata de ajuste de memoria, lo primero que debe observar es el subsistema de memoria virtual (VM, memoria virtual), que tiene una gran cantidad de opciones que pueden confundirlo.
vm.intercambio
Parámetro vm.swappiness determina cuánto usa el kernel swap (intercambio, paginación) en comparación con la RAM. También se define en el código fuente como "tendencia a robar memoria mapeada". Una alta capacidad de intercambio significa que el núcleo estará más inclinado a intercambiar páginas asignadas. Un swappiness bajo significa lo contrario: el kernel saldrá menos páginas de la memoria. En otras palabras, cuanto mayor sea el valor vm.swappiness, más usará el sistema swap.
No es deseable un gran uso del intercambio, ya que se cargan y descargan enormes bloques de datos en la RAM. Mucha gente argumenta que el valor de swapiness debería ser grande, pero en mi experiencia, establecerlo en "0" conduce a un mejor rendimiento.
Puede leer más aquí -
Pero, nuevamente, estas configuraciones deben aplicarse con cuidado y solo después de probar una aplicación en particular. Para aplicaciones de transmisión de alta carga, este parámetro debe establecerse en "0". Cuando se cambia a "0", mejora la capacidad de respuesta del sistema.
vm.vfs_cache_pression
Esta configuración controla la memoria consumida por el kernel para almacenar en caché el directorio y los objetos de inodo (entry e inode).
Con un valor predeterminado de 100, el kernel intentará liberar las cachés de inodo y dentry de manera "justa" para la caché de página y la caché de intercambio. La disminución de vfs_cache_pression hace que el núcleo conserve las cachés de dentry e inode. Cuando el valor es "0", el kernel nunca vaciará la memoria caché dentry e inode debido a la presión de la memoria, y esto puede conducir fácilmente a un error de falta de memoria. El aumento de vfs_cache_pression por encima de 100 hace que el kernel priorice el vaciado de inodos y dentry.
Al usar GlusterFS, muchos usuarios con grandes cantidades de datos y muchos archivos pequeños pueden usar fácilmente una cantidad significativa de RAM en el servidor debido al almacenamiento en caché de inodo/entry, lo que puede provocar una degradación del rendimiento ya que el kernel tiene que procesar estructuras de datos en un sistema. con 40 GB de memoria. Establecer este valor por encima de 100 ha ayudado a muchos usuarios a lograr un almacenamiento en caché más justo y una mejor capacidad de respuesta del kernel.
vm.dirty_background_ratio y vm.dirty_ratio
Primer parámetro (vm.dirty_background_ratio) determina el porcentaje de memoria con páginas sucias, después de alcanzar el cual es necesario comenzar a vaciar las páginas sucias en segundo plano en el disco. Hasta que se alcance este porcentaje, no se vaciará ninguna página en el disco. Y cuando se inicia un reinicio, se ejecuta en segundo plano sin interrumpir los procesos en ejecución.
El segundo parámetro (vm.dirty_ratio) define el porcentaje de memoria que pueden ocupar las páginas sucias antes de que comience el flash forzado. Una vez que se alcanza este umbral, todos los procesos se sincronizan (bloquean) y no se les permite continuar hasta que la E/S que solicitaron se complete realmente y los datos estén en el disco. Con una gran cantidad de E/S, esto causa un problema porque no hay almacenamiento en caché de datos y todos los procesos que realizan E/S están bloqueados esperando E/S. Esto conduce a una gran cantidad de procesos bloqueados, alta carga, inestabilidad del sistema y bajo rendimiento.
La disminución de estas configuraciones hace que los datos se descarguen en el disco con más frecuencia y no se almacenen en la RAM. Esto puede ayudar a los sistemas con mucha memoria que están de acuerdo con vaciar cachés de página de 45 a 90 GB en el disco, lo que genera una gran latencia para las aplicaciones front-end, lo que reduce la capacidad de respuesta y la interactividad en general.
"1" > /proc/sys/vm/pagecache
Un caché de página es un caché que almacena los datos de archivos y programas ejecutables, es decir, estas son páginas con el contenido real de archivos o dispositivos de bloque. Este caché se utiliza para reducir el número de lecturas de disco. Un valor de "1" significa que el 1 % de la RAM se usa para la memoria caché y habrá más lecturas del disco que de la RAM. No es necesario cambiar esta configuración, pero si está paranoico acerca de controlar el caché de la página, puede usarla.
"fecha límite" > /sys/block/sdc/queue/scheduler
El programador de E/S es un componente del kernel de Linux que maneja las colas de lectura y escritura. En teoría, es mejor usar "noop" para un controlador RAID inteligente, porque Linux no sabe nada sobre la geometría física del disco, por lo que es más eficiente dejar que el controlador, que conoce bien la geometría del disco, procese la solicitud tan rápido como sea posible. posible. Pero parece que la "fecha límite" mejora el rendimiento. Puede leer más sobre los programadores en la documentación del código fuente del kernel de Linux: linux/Documentation/block/*osched.txt. Y también he visto un aumento en el rendimiento de lectura durante operaciones mixtas (muchas operaciones de escritura).
"256" > /sys/block/sdc/queue/nr_requests
El número de solicitudes de E/S en el búfer antes de que se pasen al programador. El tamaño de la cola interna de algunos controladores (queue_ depth) es mayor que el nr_requests del programador de E/S, por lo que el programador de E/S tiene pocas posibilidades de priorizar y fusionar correctamente las solicitudes. Para programadores de fecha límite y CFQ, es mejor cuando nr_requests es 2 veces la cola interna del controlador. Las solicitudes de fusión y reordenación ayudan al programador a ser más receptivo bajo una carga pesada.
echo "16" > /proc/sys/vm/page-cluster
El parámetro page-cluster controla el número de páginas que se escriben en el intercambio al mismo tiempo. En el ejemplo anterior, el valor se establece en "16" según el tamaño de banda RAID de 64 KB. No tiene sentido con swappiness = 0, pero si establece swappiness en 10 o 20, usar este valor lo ayudará cuando el tamaño de la banda RAID sea 64K.
blockdev --setra 4096 /dev/<nombredev> (-sdb, hdc o dev_mapper)
La configuración predeterminada del dispositivo de bloque para muchos controladores RAID a menudo da como resultado un rendimiento terrible. Agregar la opción anterior configura la lectura anticipada para sectores de 4096 * 512 bytes. Al menos para las operaciones de transmisión, la velocidad aumenta al llenar el caché en disco con lectura anticipada durante el período utilizado por el núcleo para preparar la E/S. El caché puede contener datos que se solicitarán en la próxima lectura. Demasiada captación previa puede matar la E/S aleatoria para archivos grandes si consume tiempo de disco potencialmente útil o carga datos fuera de la memoria caché.
A continuación se presentan algunas recomendaciones más a nivel del sistema de archivos. Pero aún no han sido probados. Asegúrese de que su sistema de archivos conozca el tamaño de la franja y la cantidad de discos en la matriz. Por ejemplo, que se trata de una matriz raid5 de seis discos de 64 KB (en realidad cinco, porque un disco se utiliza para la paridad). Estas recomendaciones se basan en suposiciones teóricas y se compilan a partir de varios blogs/artículos de expertos en RAID.
-> ext4 fs, 5 disks, 64K stripe, units in 4K blocks
mkfs -text4 -E stride=$((64/4))
-> xfs, 5 disks, 64K stripe, units in 512-byte sectors
mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))Para archivos grandes, considere aumentar los tamaños de las franjas enumerados anteriormente.
ADVERTENCIA! Todo lo descrito anteriormente es muy subjetivo para algunos tipos de aplicaciones. Este artículo no garantiza ninguna mejora sin una prueba previa del usuario de las aplicaciones relacionadas. Solo debe usarse si es necesario para mejorar la capacidad de respuesta general del sistema o si resuelve problemas actuales.
Materiales adicionales:
Lee mas
Fuente: habr.com