{"id":95783,"date":"2020-10-03T13:42:02","date_gmt":"2020-10-03T11:42:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/nastrojka-yadra-linux-dlya-glusterfs"},"modified":"2020-10-03T13:42:02","modified_gmt":"2020-10-03T11:42:02","slug":"nastrojka-yadra-linux-dlya-glusterfs","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/nastrojka-yadra-linux-dlya-glusterfs","title":{"rendered":"Configuraci\u00f3n del n\u00facleo de Linux para GlusterFS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La traducci\u00f3n del art\u00edculo ha sido preparada en la v\u00edspera del inicio del curso \u00abAdministrador Linux. Profesional\u00bb<\/a><\/noindex>.<\/i><\/b><\/p>\n

\"Configuraci\u00f3n<\/p>\n

De vez en cuando surgen preguntas sobre las recomendaciones de Gluster respecto a la configuraci\u00f3n del n\u00facleo y si realmente son necesarias.<\/p>\n

Tal necesidad surge raramente. En la mayor\u00eda de las cargas, el n\u00facleo funciona muy bien. Aunque hay un lado opuesto. Hist\u00f3ricamente, el n\u00facleo de Linux tiende a consumir mucha memoria si se le da la oportunidad, incluso para la cach\u00e9 como principal forma de mejorar el rendimiento.<\/a><\/noindex><\/p>\n

En la mayor\u00eda de los casos, esto funciona de maravilla, pero bajo altas cargas puede conducir a problemas. <\/p>\n

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\u00edas, encontramos sobrecargas, un enorme iowait, errores del n\u00facleo (kernel oops), bloqueos, etc. <\/p>\n

Este art\u00edculo es el resultado de muchos experimentos sobre la configuraci\u00f3n de par\u00e1metros llevados a cabo en diversas situaciones. Gracias a estos ajustes no solo mejor\u00f3 la capacidad de respuesta en general, sino que tambi\u00e9n se estabiliz\u00f3 considerablemente el funcionamiento del cl\u00faster.<\/p>\n

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.<\/p>\n

vm.swappiness<\/h4>\n

\nPar\u00e1metro vm.swappiness<\/code> define cu\u00e1nto utiliza el n\u00facleo el swap en comparaci\u00f3n con la memoria RAM. En el c\u00f3digo fuente, tambi\u00e9n est\u00e1 definido como \u00abtendency to steal mapped memory\u00bb (tendencia a robar memoria mapeada). Un valor alto de swappiness significa que el n\u00facleo ser\u00e1 m\u00e1s propenso a descargar p\u00e1ginas mapeadas. Un valor bajo de swappiness significa lo contrario: el n\u00facleo descargar\u00e1 menos p\u00e1ginas de la memoria. En otras palabras, cuanto mayor sea el valor vm.swappiness<\/code>, m\u00e1s usar\u00e1 el sistema swap.<\/p>\n

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\u00eda ser alto, pero en mi experiencia, establecerlo en \u00ab0\u00bb conduce a un aumento del rendimiento.<\/p>\n

Puedes leer m\u00e1s sobre esto aqu\u00ed \u2014 lwn.net\/Articles\/100978<\/a><\/noindex> <\/p>\n

Sin embargo, estas configuraciones deben aplicarse con precauci\u00f3n y solo despu\u00e9s de probar la aplicaci\u00f3n espec\u00edfica. Para aplicaciones de transmisi\u00f3n de alta carga, este par\u00e1metro debe establecerse en \"0\". Al cambiar a \"0\", la capacidad de respuesta del sistema mejora.<\/p>\n

vm.vfs_cache_pressure<\/h4>\n

\nEste par\u00e1metro controla la memoria que el n\u00facleo consume para almacenar en cach\u00e9 objetos de directorio e \u00edndices de descriptores (dentry e inode).<\/p>\n

Con un valor predeterminado de 100, el n\u00facleo intentar\u00e1 liberar la cach\u00e9 de dentry e inode de manera \"justa\" en relaci\u00f3n con pagecache y swapcache. Reducir vfs_cache_pressure hace que el n\u00facleo mantenga las cach\u00e9s de dentry e inode. Cuando el valor es \"0\", el n\u00facleo nunca limpiar\u00e1 la cach\u00e9 de dentry e inode debido a la presi\u00f3n de memoria, lo que puede llevar f\u00e1cilmente a un error de falta de memoria. Aumentar vfs_cache_pressure por encima de 100 hace que el n\u00facleo d\u00e9 prioridad a la descarga de dentry e inode.<\/p>\n

Al usar GlusterFS, muchos usuarios con grandes vol\u00famenes de datos y muchos archivos peque\u00f1os pueden consumir una cantidad significativa de memoria en el servidor debido a la cach\u00e9 de inode\/dentry, lo que puede reducir el rendimiento, ya que el n\u00facleo tiene que manejar estructuras de datos en un sistema con 40 GB de memoria. Configurar este par\u00e1metro por encima de 100 ha ayudado a muchos usuarios a lograr una cach\u00e9 m\u00e1s justa y mejorar la capacidad de respuesta del n\u00facleo.<\/p>\n

vm.dirty_background_ratio y vm.dirty_ratio<\/h4>\n

\nEl primer par\u00e1metro (vm.dirty_background_ratio<\/code>) define el porcentaje de memoria con p\u00e1ginas sucias, alcanzando el cual se debe comenzar a realizar un volcado en segundo plano de las p\u00e1ginas sucias en el disco. Mientras no se alcance este porcentaje, las p\u00e1ginas no se volcar\u00e1n en el disco. Y cuando comienza el volcado, se lleva a cabo en segundo plano sin interrumpir los procesos en funcionamiento. <\/p>\n

El segundo par\u00e1metro (vm.dirty_ratio<\/code>) define el porcentaje de memoria que puede ser ocupado por p\u00e1ginas sucias antes de comenzar un vaciado forzado. Al alcanzar este umbral, todos los procesos se vuelven sincr\u00f3nicos (se bloquean) y no se les permite continuar hasta que la operaci\u00f3n de entrada\/salida que han solicitado se complete efectivamente y los datos est\u00e9n en el disco. En situaciones de alta carga de entrada\/salida, esto genera un problema, ya que la cach\u00e9 de datos est\u00e1 ausente y todos los procesos que realizan entrada\/salida quedan bloqueados esperando la entrada\/salida. Esto resulta en un gran n\u00famero de procesos atascados, alta carga, funcionamiento inestable del sistema y un rendimiento deficiente.<\/p>\n

Reducir los valores de estos par\u00e1metros provoca que los datos se vac\u00eden al disco m\u00e1s 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\u00e9s de p\u00e1ginas 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.<\/p>\n

\u00ab1\u00bb > \/proc\/sys\/vm\/pagecache<\/h4>\n

\nLa cach\u00e9 de p\u00e1ginas es un cach\u00e9 donde se almacenan los datos de archivos y programas ejecutables, es decir, son p\u00e1ginas con el contenido real de archivos o dispositivos de bloques. Este cach\u00e9 se utiliza para disminuir la cantidad de lecturas desde el disco. Un valor de \u00ab1\u00bb significa que se utiliza el 1% de la RAM para la cach\u00e9 y habr\u00e1 m\u00e1s operaciones de lectura desde el disco que desde la RAM. No es necesario cambiar este par\u00e1metro, pero si eres paranoico acerca del control de la cach\u00e9 de p\u00e1ginas, puedes utilizarlo.<\/p>\n

\u00abdeadline\u00bb > \/sys\/block\/sdc\/queue\/scheduler<\/h4>\n

\nEl planificador de entrada\/salida (I\/O scheduler) es un componente del n\u00facleo de Linux que maneja las colas de lectura y escritura. Te\u00f3ricamente, para un controlador RAID inteligente es mejor utilizar \u00abnoop\u00bb, porque Linux no conoce la geometr\u00eda f\u00edsica del disco, as\u00ed que es m\u00e1s eficiente permitir que el controlador, que conoce bien la geometr\u00eda del disco, procese las solicitudes lo m\u00e1s r\u00e1pido posible. Pero parece que \u00abdeadline\u00bb mejora el rendimiento. Puedes leer m\u00e1s sobre los planificadores en la documentaci\u00f3n del c\u00f3digo fuente del n\u00facleo de Linux: linux\/Documentation\/block\/*osched.txt<\/code>. Y tambi\u00e9n he observado un aumento en el rendimiento de lectura durante operaciones mixtas (muchas operaciones de escritura).<\/p>\n

\u00ab256\u00bb > \/sys\/block\/sdc\/queue\/nr_requests<\/h4>\n

\nN\u00famero de solicitudes de entrada y salida en el b\u00fafer antes de que sean enviadas al programador. El tama\u00f1o 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\u00f3n de solicitudes. Para los programadores deadline y CFQ, es mejor que nr_requests sea el doble del tama\u00f1o de la cola interna del controlador. La fusi\u00f3n y reordenamiento de solicitudes ayuda al programador a ser m\u00e1s receptivo bajo alta carga.<\/p>\n

echo \u00ab16\u00bb > \/proc\/sys\/vm\/page-cluster<\/h4>\n

\nEl par\u00e1metro page-cluster controla la cantidad de p\u00e1ginas que se escriben en el swap a la vez. En el ejemplo anterior, el valor se establece en \u00ab16\u00bb de acuerdo con el tama\u00f1o 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\u00e1 cuando el tama\u00f1o de la franja RAID sea de 64 KB.<\/p>\n

blockdev \u2014setra 4096 \/dev\/<<\/code>nombre del dispositivo><\/code> (-sdb, hdc o dev_mapper)<\/h4>\n

\nLas configuraciones predeterminadas de los dispositivos de bloque para muchos controladores RAID a menudo conducen a un rendimiento horrible. Agregar la opci\u00f3n anterior configura la lectura anticipada para sectores de 4096 * 512 bytes. Al menos, para operaciones de streaming, aumenta la velocidad al llenar el cach\u00e9 incorporado del disco mediante la lectura anticipada durante el per\u00edodo que el n\u00facleo utiliza para preparar la E\/S. Los datos que se solicitar\u00e1n en la siguiente lectura pueden almacenarse en el cach\u00e9. Una lectura anticipada excesiva puede arruinar la E\/S aleatoria para archivos grandes, si utiliza tiempo potencialmente \u00fatil del disco o carga datos m\u00e1s all\u00e1 del cach\u00e9.<\/p>\n

A continuaci\u00f3n, se presentan algunas recomendaciones a nivel del sistema de archivos. Pero a\u00fan no han sido probadas. Aseg\u00farate de que tu sistema de archivos conozca el tama\u00f1o de la franja y el n\u00famero de discos en el arreglo. Por ejemplo, que sea un arreglo RAID 5 con un tama\u00f1o de franja de 64K de seis discos (de hecho cinco, porque un disco se utiliza para paridad). Estas recomendaciones se basan en supuestos te\u00f3ricos y se recopilan de varios blogs\/art\u00edculos de expertos en RAID.<\/p>\n

-> ext4 fs, 5 discos, 64K stripe, unidades en bloques de 4K\nmkfs -text4 -E stride=$((64\/4))\n-> xfs, 5 discos, 64K stripe, unidades en sectores de 512 bytes\nmkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))<\/code><\/pre>\n
\nPara archivos grandes, se puede considerar aumentar los tama\u00f1os de franjas mencionados anteriormente.<\/p>\n
\u00a1ATENCI\u00d3N!<\/b> Todo lo descrito anteriormente es extremadamente subjetivo para ciertos tipos de aplicaciones. Este art\u00edculo 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.<\/p>\n
Material adicional:<\/h4>\n
<\/p>\n