A tradución do artigo preparouse na véspera do comezo do curso .
Periódicamente, aquí e acolá, xorden dúbidas sobre as recomendacións de Gluster relativas á axuste do núcleo e se é necesario para iso.
Tal necesidade raramente xorde. Na maioría das cargas de traballo, o núcleo funciona moi ben. Aínda que hai un inconveniente. Históricamente, o kernel de Linux estivo disposto a consumir moita memoria se se lle dá a oportunidade, incluso para almacenar na caché como a principal forma de mellorar o rendemento.
Na maioría dos casos, isto funciona ben, pero baixo unha carga pesada pode provocar problemas.
Temos moita experiencia con sistemas intensivos en memoria, como CAD, EDA e similares, que comezaron a ralentizarse baixo unha carga pesada. E ás veces atopamos problemas en Gluster. Despois de observar coidadosamente o uso da memoria e a latencia do disco durante moitos días, obtivemos a súa sobrecarga, enorme iowait, erros do núcleo (kernel oops), conxelacións, etc.
Este artigo é o resultado de moitos experimentos de afinación realizados en diversas situacións. Grazas a estes parámetros, non só mellorou a capacidade de resposta xeral, senón que o clúster tamén se estabilizou significativamente.
Cando se trata de axustar a memoria, o primeiro que hai que mirar é o subsistema de memoria virtual (VM, memoria virtual), que ten un gran número de opcións que poden confundirte.
vm.permuta
Parámetro vm.swappiness determina canto usa o kernel swap (swap, paginación) en comparación coa RAM. Tamén se define no código fonte como "tendencia a roubar memoria mapeada". Un alto intercambio significa que o núcleo estará máis inclinado a intercambiar páxinas mapeadas. Un valor de intercambio baixo significa o contrario: o núcleo fará menos páxinas da memoria. Noutras palabras, canto maior sexa o valor vm.swappiness, canto máis empregará o sistema o intercambio.
Non é desexable un gran uso do intercambio, xa que se cargan e descargan grandes bloques de datos na memoria RAM. Moitas persoas argumentan que o valor de intercambio debería ser grande, pero na miña experiencia, configuralo en "0" leva a un mellor rendemento.
Podes ler máis aquí -
Pero, de novo, estas configuracións deben aplicarse con coidado e só despois de probar unha aplicación en particular. Para aplicacións de transmisión de alta carga, este parámetro debe establecerse en "0". Cando se cambia a "0", a capacidade de resposta do sistema mellora.
vm.vfs_cache_pressure
Esta configuración controla a memoria que consume o núcleo para almacenar en caché os obxectos de directorio e inodo (dentry e inode).
Cun valor predeterminado de 100, o núcleo tentará liberar as cachés de dentry e inode de forma "xusta" para a páxina caché e a caché de intercambio. A diminución de vfs_cache_pressure fai que o núcleo manteña as cachés de dentry e inode. Cando o valor é "0", o núcleo nunca limpará a caché de dentry e inode debido á presión da memoria, e isto pode levar facilmente a un erro de falta de memoria. O aumento de vfs_cache_pressure por riba de 100 fai que o núcleo priorice o lavado de dentry e inode.
Ao usar GlusterFS, moitos usuarios con grandes cantidades de datos e moitos ficheiros pequenos poden usar facilmente unha cantidade significativa de RAM no servidor debido ao almacenamento en caché de inodos/dentry, o que pode provocar unha degradación do rendemento xa que o núcleo ten que procesar estruturas de datos nun sistema. con 40 GB de memoria. Establecer este valor por encima de 100 axudou a moitos usuarios a conseguir un almacenamento en caché máis xusto e unha mellora da capacidade de resposta do núcleo.
vm.dirty_background_ratio e vm.dirty_ratio
Primeiro parámetro (vm.dirty_background_ratio) determina a porcentaxe de memoria con páxinas sucias, despois de alcanzar o cal é necesario comezar a lavar as páxinas sucias en segundo plano ao disco. Ata que se alcance esta porcentaxe, non se lanzará ningunha páxina ao disco. E cando se inicia un reinicio, execútase en segundo plano sen interromper os procesos en execución.
O segundo parámetro (vm.dirty_ratio) define a porcentaxe de memoria que poden ocupar páxinas sucias antes de que comece o flash forzado. Unha vez alcanzado este limiar, todos os procesos fanse sincrónicos (bloqueados) e non se lles permite continuar ata que se complete a E/S que solicitaron e os datos estean no disco. Con E/S pesadas isto causa un problema porque non hai almacenamento de datos en caché e todos os procesos que fan E/S están bloqueados á espera de E/S. Isto leva a un gran número de procesos colgados, alta carga, inestabilidade do sistema e baixo rendemento.
Ao diminuír esta configuración fai que os datos se lavan ao disco con máis frecuencia e non se almacenen na memoria RAM. Isto pode axudar aos sistemas con moita memoria nos que é normal limpar cachés de páxinas de 45 a 90 GB no disco, o que provoca unha gran latencia para as aplicacións front-end, reducindo a capacidade de resposta e a interactividade xerais.
"1" > /proc/sys/vm/pagecache
Unha caché de páxina é unha caché que almacena os datos de ficheiros e programas executables, é dicir, son páxinas co contido real de ficheiros ou dispositivos de bloqueo. Esta caché úsase para reducir o número de lecturas do disco. Un valor de "1" significa que se usa o 1 % da memoria RAM para a caché e haberá máis lecturas desde o disco que desde a RAM. Non é necesario cambiar esta configuración, pero se estás paranoico ao controlar a caché da páxina, podes usalo.
"data límite" > /sys/block/sdc/queue/scheduler
O planificador de E/S é un compoñente do núcleo de Linux que xestiona as colas de lectura e escritura. En teoría, é mellor usar "noop" para un controlador RAID intelixente, porque Linux non sabe nada sobre a xeometría física do disco, polo que é máis eficiente deixar que o controlador, que coñece ben a xeometría do disco, procese a solicitude o máis rápido posible. posible. Pero parece que a "data límite" mellora o rendemento. Podes ler máis sobre os programadores na documentación de orixe do núcleo de Linux: linux/Documentation/block/*osched.txt. E tamén vin un aumento no rendemento de lectura durante operacións mixtas (moitas operacións de escritura).
"256" > /sys/block/sdc/queue/nr_requests
O número de solicitudes de E/S no búfer antes de que se pasen ao planificador. O tamaño da cola interna dalgúns controladores (queue_depth) é maior que os nr_requests do planificador de E/S, polo que o planificador de E/S ten poucas posibilidades de priorizar e fusionar correctamente as solicitudes. Para os programadores de data límite e CFQ, é mellor cando nr_requests sexa 2 veces a cola interna do controlador. A combinación e a reordenación das solicitudes axuda ao programador a ser máis sensible ante unha carga pesada.
echo "16" > /proc/sys/vm/page-cluster
O parámetro page-cluster controla o número de páxinas que se escriben no intercambio ao mesmo tempo. No exemplo anterior, o valor establécese en "16" segundo o tamaño da franxa RAID de 64 KB. Non ten sentido con swappiness = 0, pero se configuras swappiness en 10 ou 20, usar este valor axudarache cando o tamaño da franxa RAID sexa 64K.
blockdev --setra 4096 /dev/<devname> (-sdb, hdc ou dev_mapper)
A configuración predeterminada do dispositivo de bloque para moitos controladores RAID adoita producir un rendemento terrible. Ao engadir a opción anterior configúrase a lectura anticipada para sectores de 4096 * 512 bytes. Como mínimo, para as operacións de streaming, a velocidade increméntase ao encher a caché do disco no chip con lectura anticipada durante o período que utiliza o núcleo para preparar a E/S. A caché pode conter datos que se solicitarán na próxima lectura. Demasiada captura previa pode matar as E/S aleatorias para ficheiros grandes se usa tempo de disco potencialmente útil ou carga datos fóra da caché.
A continuación móstranse algunhas recomendacións máis a nivel do sistema de ficheiros. Pero aínda non foron probados. Asegúrese de que o seu sistema de ficheiros coñeza o tamaño da franxa e o número de discos da matriz. Por exemplo, que se trata dunha matriz stripe raid5 de 64K de seis discos (en realidade cinco, porque se usa un disco para a paridade). Estas recomendacións baséanse en suposicións teóricas e recompiladas a partir de varios blogs/artigos 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 ficheiros grandes, considere aumentar os tamaños de franxas indicados anteriormente.
ATENCIÓN! Todo o descrito anteriormente é altamente subxectivo para algúns tipos de aplicacións. Este artigo non garante ningunha mellora sen as probas previas do usuario das aplicacións relacionadas. Só debería utilizarse se é necesario mellorar a capacidade de resposta xeral do sistema ou se resolve os problemas actuais.
Materiais adicionais:
Le máis
Fonte: www.habr.com