La traducción del artículo ha sido preparada en la víspera del inicio del curso .
De vez en cuando surgen preguntas sobre las recomendaciones de Gluster respecto a la configuración del núcleo y si realmente son necesarias.
Tal necesidad surge raramente. En la mayoría de las cargas, el núcleo funciona muy bien. Aunque hay un lado opuesto. Históricamente, el núcleo de Linux tiende a consumir mucha memoria si se le da la oportunidad, incluso para la caché como principal forma de mejorar el rendimiento.
En la mayoría de los casos, esto funciona de maravilla, pero bajo altas cargas puede conducir a problemas.
Tenemos una gran experiencia trabajando con sistemas que consumen mucha memoria, como CAD, EDA y otros, que empezaron a ralentizarse bajo alta carga. A veces nos encontramos con problemas en Gluster. Al observar minuciosamente el uso de la memoria y el tiempo de espera de los discos durante varios días, encontramos sobrecargas, un enorme iowait, errores del núcleo (kernel oops), bloqueos, etc.
Este artículo es el resultado de muchos experimentos sobre la configuración de parámetros llevados a cabo en diversas situaciones. Gracias a estos ajustes no solo mejoró la capacidad de respuesta en general, sino que también se estabilizó considerablemente el funcionamiento del clúster.
Cuando se trata de configurar la memoria, lo primero que se debe observar es el subsistema de memoria virtual (VM, virtual memory), que tiene muchas opciones que pueden confundirte.
vm.swappiness
Parámetro vm.swappiness define cuánto utiliza el núcleo el swap en comparación con la memoria RAM. En el código fuente, también está definido como «tendency to steal mapped memory» (tendencia a robar memoria mapeada). Un valor alto de swappiness significa que el núcleo será más propenso a descargar páginas mapeadas. Un valor bajo de swappiness significa lo contrario: el núcleo descargará menos páginas de la memoria. En otras palabras, cuanto mayor sea el valor vm.swappiness, más usará el sistema swap.
Un alto uso de swap no es deseable, ya que se cargan y descargan enormes bloques de datos en la memoria RAM. Muchos afirman que el valor de swappiness debería ser alto, pero en mi experiencia, establecerlo en «0» conduce a un aumento del rendimiento.
Puedes leer más sobre esto aquí —
Sin embargo, estas configuraciones deben aplicarse con precaución y solo después de probar la aplicación específica. Para aplicaciones de transmisión de alta carga, este parámetro debe establecerse en "0". Al cambiar a "0", la capacidad de respuesta del sistema mejora.
vm.vfs_cache_pressure
Este parámetro controla la memoria que el núcleo consume para almacenar en caché objetos de directorio e índices de descriptores (dentry e inode).
Con un valor predeterminado de 100, el núcleo intentará liberar la caché de dentry e inode de manera "justa" en relación con pagecache y swapcache. Reducir vfs_cache_pressure hace que el núcleo mantenga las cachés de dentry e inode. Cuando el valor es "0", el núcleo nunca limpiará la caché de dentry e inode debido a la presión de memoria, lo que puede llevar fácilmente a un error de falta de memoria. Aumentar vfs_cache_pressure por encima de 100 hace que el núcleo dé prioridad a la descarga de dentry e inode.
Al usar GlusterFS, muchos usuarios con grandes volúmenes de datos y muchos archivos pequeños pueden consumir una cantidad significativa de memoria en el servidor debido a la caché de inode/dentry, lo que puede reducir el rendimiento, ya que el núcleo tiene que manejar estructuras de datos en un sistema con 40 GB de memoria. Configurar este parámetro por encima de 100 ha ayudado a muchos usuarios a lograr una caché más justa y mejorar la capacidad de respuesta del núcleo.
vm.dirty_background_ratio y vm.dirty_ratio
El primer parámetro (vm.dirty_background_ratio) define el porcentaje de memoria con páginas sucias, alcanzando el cual se debe comenzar a realizar un volcado en segundo plano de las páginas sucias en el disco. Mientras no se alcance este porcentaje, las páginas no se volcarán en el disco. Y cuando comienza el volcado, se lleva a cabo en segundo plano sin interrumpir los procesos en funcionamiento.
El segundo parámetro (vm.dirty_ratio) define el porcentaje de memoria que puede ser ocupado por páginas sucias antes de comenzar un vaciado forzado. Al alcanzar este umbral, todos los procesos se vuelven sincrónicos (se bloquean) y no se les permite continuar hasta que la operación de entrada/salida que han solicitado se complete efectivamente y los datos estén en el disco. En situaciones de alta carga de entrada/salida, esto genera un problema, ya que la caché de datos está ausente y todos los procesos que realizan entrada/salida quedan bloqueados esperando la entrada/salida. Esto resulta en un gran número de procesos atascados, alta carga, funcionamiento inestable del sistema y un rendimiento deficiente.
Reducir los valores de estos parámetros provoca que los datos se vacíen al disco más frecuentemente y no se mantengan en la RAM. Esto puede ayudar a sistemas con gran cantidad de memoria, donde es normal vaciar en disco cachés de páginas de 45 a 90 GB, lo que resulta en un enorme tiempo de espera para aplicaciones de frontend, disminuyendo la capacidad de respuesta e interactividad general.
«1» > /proc/sys/vm/pagecache
La caché de páginas es un caché donde se almacenan los datos de archivos y programas ejecutables, es decir, son páginas con el contenido real de archivos o dispositivos de bloques. Este caché se utiliza para disminuir la cantidad de lecturas desde el disco. Un valor de «1» significa que se utiliza el 1% de la RAM para la caché y habrá más operaciones de lectura desde el disco que desde la RAM. No es necesario cambiar este parámetro, pero si eres paranoico acerca del control de la caché de páginas, puedes utilizarlo.
«deadline» > /sys/block/sdc/queue/scheduler
El planificador de entrada/salida (I/O scheduler) es un componente del núcleo de Linux que maneja las colas de lectura y escritura. Teóricamente, para un controlador RAID inteligente es mejor utilizar «noop», porque Linux no conoce la geometría física del disco, así que es más eficiente permitir que el controlador, que conoce bien la geometría del disco, procese las solicitudes lo más rápido posible. Pero parece que «deadline» mejora el rendimiento. Puedes leer más sobre los planificadores en la documentación del código fuente del núcleo de Linux: linux/Documentation/block/*osched.txt. Y también he observado un aumento en el rendimiento de lectura durante operaciones mixtas (muchas operaciones de escritura).
«256» > /sys/block/sdc/queue/nr_requests
Número de solicitudes de entrada y salida en el búfer antes de que sean enviadas al programador. El tamaño de la cola interna de algunos controladores (queue_depth) es mayor que nr_requests del programador de E/S, por lo que el programador de E/S tiene pocas oportunidades de priorizar correctamente y ejecutar la fusión de solicitudes. Para los programadores deadline y CFQ, es mejor que nr_requests sea el doble del tamaño de la cola interna del controlador. La fusión y reordenamiento de solicitudes ayuda al programador a ser más receptivo bajo alta carga.
echo «16» > /proc/sys/vm/page-cluster
El parámetro page-cluster controla la cantidad de páginas que se escriben en el swap a la vez. En el ejemplo anterior, el valor se establece en «16» de acuerdo con el tamaño de franja (stripe size) del RAID de 64 KB. Esto no tiene sentido con swappiness = 0, pero si lo has configurado en 10 o 20, usar este valor te ayudará cuando el tamaño de la franja RAID sea de 64 KB.
blockdev --setra 4096 /dev/<nombre del dispositivo> (-sdb, hdc o dev_mapper)
Las configuraciones predeterminadas de los dispositivos de bloque para muchos controladores RAID a menudo conducen a un rendimiento horrible. Agregar la opción anterior configura la lectura anticipada para sectores de 4096 * 512 bytes. Al menos, para operaciones de streaming, aumenta la velocidad al llenar el caché incorporado del disco mediante la lectura anticipada durante el período que el núcleo utiliza para preparar la E/S. Los datos que se solicitarán en la siguiente lectura pueden almacenarse en el caché. Una lectura anticipada excesiva puede arruinar la E/S aleatoria para archivos grandes, si utiliza tiempo potencialmente útil del disco o carga datos más allá del caché.
A continuación, se presentan algunas recomendaciones a nivel del sistema de archivos. Pero aún no han sido probadas. Asegúrate de que tu sistema de archivos conozca el tamaño de la franja y el número de discos en el arreglo. Por ejemplo, que sea un arreglo RAID 5 con un tamaño de franja de 64K de seis discos (de hecho cinco, porque un disco se utiliza para paridad). Estas recomendaciones se basan en supuestos teóricos y se recopilan de varios blogs/artículos de expertos en RAID.
-> ext4 fs, 5 discos, 64K stripe, unidades en bloques de 4K
mkfs -text4 -E stride=$((64/4))
-> xfs, 5 discos, 64K stripe, unidades en sectores de 512 bytes
mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))Para archivos grandes, se puede considerar aumentar los tamaños de franjas mencionados anteriormente.
¡ATENCIÓN! Todo lo descrito anteriormente es extremadamente subjetivo para ciertos tipos de aplicaciones. Este artículo no garantiza mejoras sin pruebas previas de las aplicaciones correspondientes por parte del usuario. Debe aplicarse solo en caso de ser necesario para mejorar la capacidad de respuesta general del sistema o si resuelve problemas actuales.
Material adicional:
Leer más
Fuente: habr.com
