En la primera parte de esta serie, analicé los conceptos básicos de cgroups y cómo los cgroups ayudan a administrar el rendimiento y la seguridad en servidores Linux. Aquí, en la segunda parte, discuto el valor de CPUShares y cómo lo usa cgroups. No olvide que en la tercera parte analizo la administración de cgroup y en la cuarta concluyo con cgroups a medida que interactúan con systemd.
Un poco sobre los ascensores de Linux
Voy a centrarme muy poco en Red Hat Enterprise Linux (RHEL) para esta sección. Sin embargo, en mi vistazo rápido a las pocas cajas de Ubuntu en mi laboratorio, noté similitudes con el programador de E/S. Por lo tanto, algunos de mis puntos también podrían aplicarse a otras distribuciones. La mayoría de la familia de productos de Red Hat (Fedora, CentOS y RHEL) utilizan deadline o cfq como programadores predeterminados.
- Cola completamente justa (CFQ):enfatiza la E/S proveniente de procesos en tiempo real y utiliza datos históricos para decidir si una aplicación emitirá más solicitudes de E/S en el futuro cercano.
- Fecha límite:intenta proporcionar una latencia garantizada para las solicitudes y es particularmente adecuado cuando las operaciones de lectura ocurren con más frecuencia que las operaciones de escritura. Hay una cola para lecturas y otra para escrituras. Las operaciones se completan en función del tiempo pasado en la cola, y el kernel siempre intentará procesar las solicitudes antes de que haya transcurrido su cantidad máxima de tiempo. Las operaciones de lectura tienen prioridad sobre los lotes de escritura de forma predeterminada.
Con eso en mente, RHEL tiende a usar cfq para unidades basadas en SATA y deadline para todos los demás casos por defecto. Esto juega un papel importante en el ajuste de su sistema. Estos programadores se pueden cambiar, por supuesto, y debe investigar su carga de trabajo y elegir el programador que mejor se adapte a sus tareas. También vale la pena señalar que se puede elegir un programador por dispositivo de bloque . Esto significa que podría tener múltiples programadores en un solo sistema, dependiendo de cómo estén configurados sus discos.
[ También te puede interesar:Configurar servidores SSH en contenedores para grabar sesiones con tlog ]
Uso compartido de CPU
Los usos compartidos de CPU El valor proporciona tareas en un cgroup con una cantidad relativa de tiempo de CPU. Una vez que el sistema haya montado el controlador cpu cgroup, puede usar el archivo cpu.shares para definir el número de acciones asignadas al cgroup. El tiempo de CPU se determina dividiendo los recursos compartidos de CPU de cgroup por el número total de recursos compartidos de CPU definidos en el sistema. Esta matemática del tiempo de CPU se vuelve bastante complicada, así que veamos algunos diagramas para aclarar las cosas.
El diagrama anterior representa algunos de los elementos más comunes en un servidor de plano de control de RHEL 7 OpenShift Container Platform. Cada proceso en este sistema comienza con / cgrupo.
En RHEL, esto comienza con la raíz / cgroup con 1024 recursos compartidos y el 100 % de los recursos de la CPU. El resto de los recursos se dividen a partes iguales entre los grupos /system.slice , /user.slice y /kubepod.slice , cada uno con un peso igual de 1024 por defecto, como se ve a continuación:
En este escenario, la lógica es bastante sencilla:cada porción puede usar solo el 33 % de las CPUShares si todos los cgroups exigen acciones simultáneamente. La matemática es bastante simple:
Y cuando conectas los números:
Sin embargo, ¿qué sucede si decide anidar grupos o cambiar el peso de los grupos en el mismo nivel? A continuación se muestra un ejemplo de los grupos anidados:
En este ejemplo, ves que he creado un cgroup para diferentes usuarios. Aquí es donde las matemáticas se ponen interesantes. Al principio, pensarías que la siguiente ecuación funcionaría bien:
Sin embargo, esto es solo el 23 % del 33 % asignado al user.slice . Eso significa usuario1 tiene aproximadamente el 7,6 % del tiempo total de CPU en función de estos pesos en caso de contención de recursos.
CPUShares se complicó rápidamente. Afortunadamente, la mayoría de los otros controladores son más sencillos que este.
[ ¿Empezando con los contenedores? Consulta este curso gratuito. Implementación de aplicaciones en contenedores:una descripción técnica general. ]
Resumir
Los valores de CPUShares pueden hacer que cgroups parezca realmente complejo. Eso es parte de por qué quería cubrir CPUShares aquí. Sin embargo, el uso adecuado de CPUShares lo ayuda a administrar su sistema de manera más eficiente y precisa.
En el próximo artículo de esta serie, analizo la administración de cgroup. Espero que sigas siguiendo esta serie. En la cuarta parte terminaré nuestra discusión con systemd y cgroups.