Nos ocuparemos de los reguladores del subsistema de almacenamiento de datos y veremos qué le permiten hacer en el sentido de bloque de E / S.
Lo que es especialmente interesante aquí es que estamos entrando en un territorio donde los cambios en la configuración que se realizan después del lanzamiento del sistema son mucho menos importantes que las decisiones que se toman incluso antes de su implementación.
Echa un vistazo a la imagen de abajo.
Presenta cuatro recursos principales que una computadora moderna necesita para funcionar correctamente. El ajuste del rendimiento es el arte de distribuir de manera óptima estos recursos entre los procesos de la aplicación. Además, todos estos recursos no son ilimitados ni equivalentes en términos de impacto en la productividad.
El rendimiento del subsistema de almacenamiento se reduce al rendimiento de las tecnologías de almacenamiento utilizadas en él: discos duros, SSD, SAN, NAS: pueden variar mucho en velocidad de acceso y rendimiento. Y un procesador potente y mucha memoria no salvarán la situación si los dispositivos de almacenamiento no cumplen con los requisitos de las tareas que se están resolviendo.
Si usted, como especialista en Linux, puede influir en las decisiones de hardware, intente asegurarse de que su organización tenga una plataforma de almacenamiento adecuada (o superior). Esto ahorrará muchos problemas en el futuro.
Ahora veamos qué se puede hacer con la ayuda de los controles de entrada / salida (E / S).
Se trata de dispositivos de almacenamiento.
Oficialmente, el controlador de E / S se llama blkio, pero de buen humor, responde a Blocky. Al igual que el controlador de la CPU, Blocky tiene dos modos de operación:
- Ajuste mediante bolas de E / S relativas (recursos compartidos), que le permiten controlar el rendimiento a nivel de todos los dispositivos de almacenamiento de bloques seleccionados seleccionando valores en el rango de 10 a 1000. Por defecto, se usa 1000, por lo que cualquier cambio solo reduce las bolas de E / S El usuario o servicio seleccionado. ¿Por qué 1000, no 1024, como en el caso de la CPU? Buena pregunta Aparentemente, este es el caso cuando la naturaleza abierta de Linux no es buena para él.
- Ajuste absoluto del ancho de banda para limitar la velocidad de lectura y / o escritura para un usuario o servicio determinado. Por defecto, este modo está deshabilitado.
La captura de pantalla siguiente muestra los parámetros que se pueden ajustar con el comando systemctl. Aquí usamos la magia de las indicaciones automáticas en la tecla Tab para mostrar una lista de opciones. Esto se llama bash-complete, y si todavía no está utilizando esta función, es hora de instalar el PRM apropiado.
Las bolas de E / S relativas están controladas por los parámetros BlockIODeviceWeight y BlockIOWeight. Antes de jugar con estos controladores, debe comprender esto: solo funcionan si el Programador de E / S CFQ está habilitado para el dispositivo de almacenamiento.
¿Qué es un planificador de E / S? Comencemos desde lejos y recordemos que el kernel de Linux es responsable de garantizar que todos los componentes de hardware de la computadora se comuniquen entre sí correctamente. Y dado que todos estos componentes al mismo tiempo quieren cosas diferentes, uno no puede prescindir de ordenar. Bueno, ¿cómo, por ejemplo, organizamos nuestra vida, estructurándola para el trabajo, el descanso, el sueño, etc.
Si hablamos de dispositivos de almacenamiento, entonces el planificador de E / S es responsable de organizar su trabajo dentro del núcleo. Este es solo un código de programa que define una forma de controlar el flujo de datos para dispositivos de bloque, que van desde unidades flash USB y discos duros a discos virtuales, que en realidad son archivos en algún lugar de dispositivos ISCI en una SAN.
Y además de todos estos dispositivos que se pueden usar en Linux, hay varias tareas que una computadora debe realizar. Además, en la vida real, existe lo que en Red Hat llamamos "casos de uso". Es por eso que hay diferentes planificadores enfocados en diferentes escenarios. Estos planificadores se llaman noop, deadline y cfq. En pocas palabras, cada uno de ellos se puede describir de la siguiente manera:
- Noop: adecuado para dispositivos de almacenamiento en bloque que no tienen piezas giratorias (flash, ssd, etc.).
- Deadline es un programador liviano enfocado en minimizar los retrasos. Por defecto, da prioridad a la lectura a expensas de la escritura, ya que la mayoría de las aplicaciones tropiezan con la lectura.
- Cfq: se centró en la distribución equitativa del ancho de banda de E / S a nivel de todo el sistema. Y como dijimos anteriormente, este es el único programador que admite opciones de E / S relativas para cgroups.
Para obtener más información sobre los planificadores , consulte la Guía de ajuste de rendimiento de Red Hat Enterprise Linux 7.
¿Cuál fue toda esta discusión sobre los planificadores? Además, en la mayoría de las computadoras, cfq NO SE UTILIZA por defecto si no tienen unidades SATA. Sin saber esto, puede cambiar BlockIOWeight hasta que se vuelva azul sin ningún efecto. Desafortunadamente, systemd no le dirá: “Lo siento, está intentando en vano cambiar este parámetro. Esto no funcionará porque el dispositivo está usando el programador incorrecto ".
Entonces, ¿cómo puede conocer esta característica "interesante"? Como de costumbre, de la documentación de cgroups sobre la que escribimos en una publicación anterior. Siempre es útil familiarizarse con él antes de usar estos o aquellos reguladores.
Pasamos al caso de uso
Nuevamente pasamos de las palabras generales a las específicas: déjame presentarte al Sr. Kryakin.
Se dedica a la restauración y tiene dos bases de datos en el servidor de aplicaciones para el seguimiento de pedidos. El Sr. Kryakin insiste en que la base de datos de pedidos de platos de pato es mucho más importante que la base de platos de ganso, ya que los gansos son impostores en el trono de las aves acuáticas.
Ambas bases de datos están configuradas como servicios, y sus archivos unitarios se ven así:
De hecho, los scripts llamados en ellos (duck.sh y goose.sh) no hacen ningún trabajo real en la base de datos, sino que solo simulan la lectura y la escritura usando bucles de comando dd. Ambas secuencias de comandos utilizan el sistema de archivos / database, que se encuentra en su disco virtual.
Vamos a correr pato y ganso y ver dónde aterrizan en la jerarquía cgroup:
Y ahora, dado que conocemos los PID de los procesos dd, pasemos al comando iotop para ver qué sucede en el subsistema de almacenamiento:
Bueno, 12-14 MB / s ... no rápido. Parece que el Sr. Kryakin no invirtió mucho en el sistema de almacenamiento de datos. Aunque ya teníamos preguntas sobre su adecuación, no hay mucho de qué sorprenderse.
Ahora nos fijamos en nuestras dos tareas: PID 3301 (ganso) y PID 3300 (pato). Cada uno usa E / S en algún lugar alrededor de 6 MB / s. La pantalla de arriba es un número un poco diferente, pero en realidad están saltando constantemente, y en promedio, estas dos tareas comparten el ancho de banda del dispositivo de almacenamiento por igual.
El Sr. Kryakin quiere que el pato tenga al menos 5 veces más ancho de banda de E / S que el ganso, por lo que las órdenes de pato siempre se procesan primero. Intentemos usar el parámetro BlockIOWeight para esto con los siguientes comandos:
Observamos iotop y vemos que no funcionó:
Verifiquemos el planificador de E / S para el dispositivo / dev / vdb:
Interesante ... Estamos tratando de cambiar el programador a cfq y no sale nada. Por qué
El hecho es que nuestro sistema se ejecuta en una máquina virtual KVM, y resulta que a partir de la versión 7.1, el
programador ya no se
puede cambiar en Red Hat Enterprise Linux. Y esto no es un error, sino una característica relacionada con la mejora de los mecanismos para trabajar con dispositivos de E / S virtualizados.
Pero no nos desesperemos. Tenemos dos parámetros más que se pueden cambiar: BlockIOReadBandwidth y BlockIOWriteBandwidth funcionan en el nivel del dispositivo de bloque e ignoran el programador de E / S. Como conocemos el ancho de banda del dispositivo / dev / vdb (alrededor de 14 MB / s para recepción y salida), limitando el ganso a 2 MB / s, parece que podemos cumplir el deseo del Sr. Kryakin. Probemos
Buscamos: ¡PID 3426, también conocido como ganso, ahora usa E / S en algún lugar alrededor de 2 MB / sy PID 3425, es decir, pato, para casi todos los 14!
Hurra, hicimos lo que el cliente quería, lo que significa que salvamos no solo un cierto número de gansos, sino también nuestra reputación como gurú de Linux.