En la primera parte, analicé la función y el uso de cgroups para la administración del sistema y el ajuste del rendimiento. En la segunda parte, noté la complejidad de los valores de cgroups y CPUShares. Aquí, en la tercera parte, me centro en las tareas administrativas manuales para cgroups.
No olvide leer en la cuarta parte sobre cómo funcionan los grupos c con systemd.
Haciendo cgroups de la manera difícil
Echemos un vistazo a cómo crear cgroups sin ninguna de las herramientas que los rodean. En esencia, los cgroups son simplemente una estructura de directorios con cgroups montado en ellos. Se pueden ubicar en cualquier parte del sistema de archivos, pero encontrará los cgroups creados por el sistema en /sys/fs/cgroup por defecto. Entonces, ¿cómo se crean cgroups? Comience creando el siguiente directorio de nivel superior:
# mkdir -p /my_cgroups Después de crear esto, decida qué controladores desea usar. Recuerde que la estructura de la versión 1 de cgroups se ve así:
/my_cgroups
├── <controller type>
│ ├── <group 1>
│ ├── <group 2>
│ ├── <group 3> [ A los lectores también les gustó:Una introducción a crun, un tiempo de ejecución de contenedores rápido y con poca memoria ]
Todos los grupos que desea crear se anidan por separado en cada tipo de controlador. Por lo tanto, grupo1 bajo el controlador memory es completamente independiente de group1 en blkio . Con eso en mente, creemos un ejemplo básico de CPUShares.
Para simplificar, generaré una carga en el sistema ejecutando:
# cat /dev/urandom Esto pone algo de carga artificial en el sistema para facilitar la medición. Este no es un ejemplo de carga del mundo real, pero destaca los puntos principales de CPUShares. También configuré una máquina virtual que ejecuta CentOS 8 con una sola vCPU para que las matemáticas sean realmente simples. Con eso en mente, el primer paso es crear algunos directorios para nuestros controladores cgroup:
# mkdir -p /my_cgroups/{memory,cpusets,cpu} A continuación, monte los cgroups en estas carpetas:
# mount -t cgroup -o memory none /my_cgroups/memory
# mount -t cgroup -o cpu,cpuacct none /my_cgroups/cpu
# mount -t cgroup -o cpuset none /my_cgroups/cpusets
Para crear sus propios cgroups, simplemente cree un nuevo directorio bajo el controlador que desea utilizar. En este caso, estoy tratando con el archivo cpu.shares , que se encuentra en la cpu directorio. Así que vamos a crear un par de cgroups debajo de cpu controlador:
# mkdir -p /my_cgroups/cpu/{user1,user2,user3} Tenga en cuenta que el controlador rellena automáticamente los directorios:
# ls -l /my_cgroup/cpu/user1/
-rw-r--r--. 1 root root 0 Sep 5 10:26 cgroup.clone_children
-rw-r--r--. 1 root root 0 Sep 5 10:26 cgroup.procs
-r--r--r--. 1 root root 0 Sep 5 10:26 cpuacct.stat
-rw-r--r--. 1 root root 0 Sep 5 10:26 cpuacct.usage
-r--r--r--. 1 root root 0 Sep 5 10:26 cpuacct.usage_all
-r--r--r--. 1 root root 0 Sep 5 10:26 cpuacct.usage_percpu
-r--r--r--. 1 root root 0 Sep 5 10:26 cpuacct.usage_percpu_sys
-r--r--r--. 1 root root 0 Sep 5 10:26 cpuacct.usage_percpu_user
-r--r--r--. 1 root root 0 Sep 5 10:26 cpuacct.usage_sys
-r--r--r--. 1 root root 0 Sep 5 10:26 cpuacct.usage_user
-rw-r--r--. 1 root root 0 Sep 5 10:26 cpu.cfs_period_us
-rw-r--r--. 1 root root 0 Sep 5 10:26 cpu.cfs_quota_us
-rw-r--r--. 1 root root 0 Sep 5 10:26 cpu.rt_period_us
-rw-r--r--. 1 root root 0 Sep 5 10:26 cpu.rt_runtime_us
-rw-r--r--. 1 root root 0 Sep 5 10:20 cpu.shares
-r--r--r--. 1 root root 0 Sep 5 10:26 cpu.stat
-rw-r--r--. 1 root root 0 Sep 5 10:26 notify_on_release
-rw-r--r--. 1 root root 0 Sep 5 10:23 tasks Ahora que tengo algunos cgroups configurados, es hora de generar algo de carga. Para esto, simplemente abro tres sesiones SSH y ejecuto el siguiente comando en primer plano:
# cat /dev/urandom
Puedes ver los resultados en top :
NOTA IMPORTANTE :Recuerde que los CPUShares se basan en el cgroup de nivel superior, que no tiene restricciones de forma predeterminada. Esto significa que si un proceso más arriba en el árbol demanda CPUShares, el sistema le dará prioridad a ese proceso. Esto puede confundir a la gente. Es vital tener una representación visual del diseño de cgroup en un sistema para evitar confusiones.
En la captura de pantalla anterior, puedes ver que todos los cat los procesos reciben más o menos la misma cantidad de tiempo de CPU. Esto se debe a que, de forma predeterminada, a los cgroups se les da un valor de 1024 en cpu.shares . Estas acciones están restringidas por la relación de la matriz con otros cgroups, como se discutió anteriormente. En nuestro ejemplo, no he ajustado el peso de ninguno de los padres. Por lo tanto, si todos los cgroups primarios demandan recursos simultáneamente, se aplica el peso predeterminado de 1024 CPUShares.
Volviendo a nuestro ejemplo, he creado un cgroup con algunos valores predeterminados. Eso significa que cada grupo tiene el peso predeterminado de 1024. Para cambiar esto, simplemente cambie los valores en cpu.shares archivo:
# echo 2048 > user1/cpu.shares
# echo 768 > user2/cpu.shares
# echo 512 > user3/cpu.shares
Excelente, ahora tengo un cálculo de ponderación más complicado, pero en realidad no he agregado ningún proceso al cgroup. Por lo tanto, el cgroup está inactivo. Para agregar un proceso a un cgroup, simplemente agregue el PID deseado a las tasks archivo:
# echo 2023 > user1/tasks
Este es el resultado de agregar un proceso a un cgroup como se ve en top :
Como puede ver en la captura de pantalla anterior, el proceso en el nuevo cgroup recibe aproximadamente la mitad del tiempo de CPU. Esto se debe a la ecuación anterior:
Avancemos y agreguemos los otros dos procesos en sus respectivos cgroups y observemos los resultados:
# echo 2024 > user2/tasks
# echo 2025 > user3/tasks 
Ahora vemos que la ponderación ha tenido efecto, con el cgroup user1 tomando alrededor del 61% del tiempo de CPU:
El tiempo restante se divide entre usuario2 y usuario3 .
Hay, por supuesto, varios problemas con nuestra configuración de prueba.
- Todos estos son creados a mano. ¿Qué sucede si el proceso que está colocando en un cgroup cambia su PID?
- Los archivos y carpetas personalizados creados no sobrevivirán a un reinicio.
- Esto es mucho trabajo manual. ¿Dónde está la herramienta?
No teman, mis amigos, systemd lo tiene cubierto.
[ Curso gratuito en línea:Descripción general técnica de Red Hat Enterprise Linux. ]
Terminar
Ahora que comprendemos mejor la administración manual de cgroups, podemos apreciar mejor el valor de cgroups y systemd trabajando juntos. Examino esa idea en la cuarta parte de esta serie. Por cierto, la cuarta parte es la conclusión.