De vez en cuando, surgen preguntas aquí y allá sobre las recomendaciones de Gluster con respecto al ajuste del kernel y si es necesario.
Esa necesidad es rara. El kernel funciona muy bien en la mayoría de las cargas de trabajo. Aunque hay una desventaja. Históricamente, el kernel de Linux consume fácilmente mucha memoria si se le da la oportunidad, incluso para el almacenamiento en caché como la principal forma de mejorar el rendimiento.
La mayoría de las veces esto funciona bien, pero con una carga pesada puede ocasionar problemas.
Tenemos mucha experiencia con sistemas que consumen mucha memoria, como CAD, EDA y similares, que empezaron a ralentizarse con cargas elevadas. Y a veces nos encontramos con problemas con Gluster. Después de observar cuidadosamente la memoria utilizada y la latencia de los discos durante más de un día, obtuvimos su sobrecarga, iowait enorme, errores del kernel (kernel oops), congelamientos, etc.
Este artículo es el resultado de muchos experimentos de ajuste realizados en diversas situaciones. Estos parámetros no solo mejoraron la capacidad de respuesta general, sino que también estabilizaron significativamente el rendimiento del clúster.
Cuando se trata del ajuste de la memoria, lo primero que hay que tener en cuenta es el subsistema de memoria virtual (VM), que tiene una gran cantidad de opciones que pueden confundirlo.
vm.swappiness
Este parámetro
vm.swappinessdetermina cuánto usa el kernel swap (swap) en comparación con la RAM. En el código fuente, también se define como "tendencia a robar memoria mapeada" (tendencia a robar memoria mapeada). Un valor de intercambio alto significa que el kernel será más propenso a descargar páginas renderizadas. Un valor de intercambio bajo significa lo contrario: el kernel intercambiará menos páginas de la memoria. En otras palabras, cuanto mayor sea el valor vm.swappiness, más intercambiará el sistema.
No es deseable un gran uso del intercambio, ya que se cargan y descargan grandes bloques de datos en la RAM. Mucha gente sostiene que el valor de intercambio debería ser alto, pero en mi experiencia, establecerlo en "0" aumentará el rendimiento.
Puede leer más detalles aquí -lwn.net/Articles/100978
Pero, nuevamente, estas configuraciones deben aplicarse con precaución 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". Cambiar a "0" mejora la capacidad de respuesta del sistema.
vm.vfs_cache_pressure
Este parámetro controla la memoria consumida por el kernel para almacenar en caché los objetos de directorio y los inodos (dentry e inode).
Con el valor predeterminado de 100, el kernel intentará liberar los cachés dentry e inode para ser justos en pagecache y swapcache. Disminuir vfs_cache_pressure hace que el kernel mantenga los cachés dentry e inode. Cuando el valor es 0, el kernel nunca borrará los cachés dentry e inode debido a una presión de memoria insuficiente, y esto puede conducir fácilmente a un error de memoria insuficiente. El aumento de vfs_cache_pressure por encima de 100 hace que el kernel dé prioridad a la descarga de inodos y dentry.
Con 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 / dentry, lo que puede llevar a 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 parámetro 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
El primer parámetro (
vm.dirty_background_ratio) define el porcentaje de memoria con páginas sucias, después de lo cual es necesario iniciar un vaciado en segundo plano de las páginas sucias al disco. Hasta que se alcance este porcentaje, no se vacían páginas en el disco. Y cuando se inicia el 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. Cuando se alcanza este umbral, todos los procesos se vuelven síncronos (bloqueados) y no se les permite continuar ejecutándose hasta que la E / S solicitada por ellos se complete realmente y los datos estén en el disco. Con una alta carga de E / S, esto causa un problema, ya que 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 congelados, alta carga, operación inestable del sistema y bajo rendimiento.
La disminución de los valores de estos parámetros conduce al hecho de que los datos se descargan con mayor frecuencia en el disco y no se almacenan en la RAM. Esto puede ayudar a los sistemas con mucha memoria, para lo cual está bien vaciar la caché de página de 45 a 90 GB, lo que da como resultado una latencia enorme para las aplicaciones de front-end, lo que reduce la capacidad de respuesta y la interactividad en general.
"1"> / proc / sys / vm / pagecache
Una caché de página es una caché que almacena datos para archivos y programas ejecutables, es decir, estas son páginas con el contenido real de archivos o dispositivos de bloque. Esta caché se utiliza para reducir la cantidad de lecturas de disco. Un valor de "1" significa que la caché usa el 1% de la RAM y habrá más lecturas del disco que de la RAM. No es necesario cambiar este parámetro, pero si está paranoico acerca del control sobre la caché de la página, puede usarlo.
Fecha límite> / sys / block / sdc / queue / Scheduler
El programador de E / S es el 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 un controlador con un buen conocimiento de la geometría del disco procese la solicitud lo más rápido posible. Pero la fecha límite parece mejorar el rendimiento. Para obtener más información acerca de los programadores se pueden encontrar en la documentación para el código fuente del kernel de Linux:
linux/Documentation/block/*osched.txt. Y también vi un aumento en el rendimiento de lectura durante operaciones mixtas (muchas escrituras).
"256"> / sys / block / sdc / queue / nr_requests
El número de solicitudes de E / S en el búfer antes de que se envíen al planificador. Algunos controladores tienen un tamaño de cola interno (queue_depth) mayor que los nr_requests del programador de E / S, por lo que el programador de E / S tiene pocas posibilidades de priorizar y fusionar las solicitudes correctamente. Para los programadores de fecha límite y CFQ, es mejor cuando nr_requests es 2 veces la cola interna del controlador. Combinar y reordenar consultas ayuda al planificador a responder mejor en situaciones de gran carga.
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 a la vez. En el ejemplo anterior, el valor se establece en "16" para que coincida con el tamaño de banda de 64 KB del RAID. No tiene sentido con swappiness = 0, pero si establece swappiness en 10 o 20, usar este valor le ayudará cuando el tamaño de la banda RAID sea de 64 KB.
blockdev --setra 4096 / dev / <devname >(-sdb, hdc o dev_mapper)
La configuración predeterminada del dispositivo de bloqueo para muchos controladores RAID a menudo conduce a un rendimiento terrible. Al agregar la opción anterior, se configura la lectura anticipada para sectores de 4096 * 512 bytes. Al menos para las operaciones de transmisión, la velocidad aumenta llenando el caché del disco integrado con lectura anticipada durante el período que tarda el kernel en preparar E / S. La caché puede contener datos que se solicitarán en la próxima lectura. Demasiada lectura anticipada puede matar la E / S aleatoria para archivos grandes si está usando tiempo de disco potencialmente útil o cargando datos fuera de la caché.
A continuación se presentan algunas pautas más a nivel del sistema de archivos. Pero aún no se han probado. Asegúrese de que su sistema de archivos conozca el tamaño de la banda y la cantidad de discos en la matriz. Por ejemplo, es una matriz raid5 con un tamaño de banda de 64K de seis discos (en realidad, cinco porque se usa un disco para la paridad). Estas recomendaciones se basan en suposiciones teóricas y se recopilan de varios blogs / artículos por 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 banda anteriores.
¡ATENCIÓN! Todo lo descrito anteriormente es extremadamente subjetivo para algunos tipos de aplicaciones. Este artículo no garantiza ninguna mejora sin la prueba previa del usuario de las aplicaciones respectivas. Solo debe usarse si es necesario para mejorar la capacidad de respuesta general del sistema o si resuelve problemas actuales.
Materiales adicionales:
- dom.as/2008/02/05/linux-io-schedulers
- www.nextre.it/oracledocs/oraclemyths.html
- lkml.org/lkml/2006/11/15/40
- misterd77.blogspot.com/2007/11/3ware-hardware-raid-vs-linux-software.html
Lee mas