Cómo administrar grupos de control con CPUShares

Dentro parte uno En esta serie, he discutido los conceptos básicos de los grupos de control y cómo los grupos de control ayudan a administrar el rendimiento y la seguridad en los servidores Linux. Aquí, en la Parte 2, analizo el valor de CPUShares y su uso por parte de los grupos de control. Tenga en cuenta que en la tercera parte analizo la administración de cgroups, y en la cuarta parte concluyo con cgroups cuando interactúan con systemd.

Índice

    Un poco sobre los ascensores de Linux

    Me centraré muy de cerca en Red Hat Enterprise Linux (RHEL) para esta sección. Sin embargo, al echar un vistazo rápido a las pocas cajas de Ubuntu en mi laboratorio, noté algunas similitudes con el I/O Scheduler. Por lo tanto, algunos de mis puntos también podrían aplicarse a otras distribuciones. La mayoría de los productos de la familia Red Hat (Fedora, CentOS y RHEL) utilizan deadline Donde cfq como planificadores predeterminados.

    • Cola completamente justa (CFQ): se centra en la E/S de los procesos en tiempo real y utiliza datos históricos para decidir si una aplicación emitirá más solicitudes de E/S en un futuro próximo.
    • Retraso: 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 terminan en función de la cantidad de tiempo que pasan en la cola y el kernel siempre intentará procesar las solicitudes antes de que haya transcurrido su tiempo máximo. Las operaciones de lectura tienen prioridad sobre los lotes de escritura de forma predeterminada.

    Con esto en mente, RHEL tiende a usar cfq para unidades SATA y deadline para todos los demás casos por defecto. Esto juega un papel importante en el ajuste de su sistema. Estos planificadores se pueden cambiar, por supuesto, y necesita estudiar su carga de trabajo y elegir el planificador que mejor se adapte a sus tareas. También vale la pena señalar que se puede elegir un programador. Esto significa que puede tener múltiples programadores en un solo sistema, según la configuración de su disco.

    Acciones de CPU

    El valor proporciona tareas en un cgroup con una cantidad relativa de tiempo de CPU. Después de que el sistema haya montado el controlador de cpu cgroup, puede usar el archivo cpu.shares para definir el número de acciones asignadas al grupo de control. El tiempo de CPU se determina dividiendo los recursos compartidos de CPU en el grupo de control por el número total de recursos compartidos de CPU definidos en el sistema. Este cálculo del tiempo de CPU se está volviendo bastante complicado, así que veamos algunos diagramas para aclarar las cosas.

    El diagrama anterior muestra 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 la / grupo de control.

    En RHEL, comienza con la raíz / cgroup con 1024 recursos compartidos y 100 % de recursos de CPU. El resto de los recursos se distribuyen equitativamente entre los grupos. /system.slice, /user.slice, y /kubepod.slice, cada uno con un peso igual de 1024 por defecto, como se muestra a continuación:

    En este escenario, la lógica es bastante simple: cada porción solo puede usar el 33 % de las CPUShares si todos los cgroups solicitan acciones simultáneamente. El cálculo es bastante simple:

    Y cuando conectas los números:

    Sin embargo, ¿qué sucede si decide anidar grupos o cambiar el peso de los grupos del mismo nivel? Aquí hay un ejemplo de 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, podría pensar que la siguiente ecuación funcionaría bien:

    Sin embargo, esto solo representa el 23% del 33% destinado a user.slice. Eso significa usuario1 tiene aproximadamente el 7,6 % del tiempo total de CPU en función de estas ponderaciones de conflicto de recursos.

    CPUShares se complicó rápidamente. Afortunadamente, la mayoría de los otros controladores son más simples que este.

    Conclusión

    Los valores de CPUShares pueden hacer que cgroups sea muy 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 grupos de control. Espero que sigas esta serie. En la cuarta parte, terminaré nuestra discusión con systemd y cgroups.

    Artículos de interés

    Subir