Tengo dos instancias de 32 vCPU en AWS/GCP. Estoy intentando configurar el blindaje de la CPU para que el sistema utilice las CPU 0, 1 y las CPU 2-31 estén protegidas y solo las utilicen explícitamente los subprocesos del espacio de usuario.
Información del sistema:
Distributor ID: Ubuntu
Description: Ubuntu 22.04.1 LTS
Release: 22.04
Codename: jammy
$ cat /proc/filesystems | grep cpuset
nodev cpuset
Sin embargo, cuando intento ejecutar cset shield, aparece un error relacionado con los montajes:
mount: /cpusets: none already mounted on /run/credentials/systemd-sysusers.service.
cset: **> mount of cpuset filesystem failed, do you have permission?
He investigado un poco el código cset y parece que la llamada fallida es una de
$ sudo mount -t cpuset cpuset /cpusets
mount: /cpusets: cpuset already mounted or mount point busy.
/cpusetses una carpeta recién creada y $ cat /proc/mounts | grep cpusetestá vacía, por lo que cpuset no parece estar montado en otro lugar.
Quizás relevante:
$ cat /proc/mounts | grep cgroup
cgroup2 /sys/fs/cgroup cgroup2 rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot 0 0
Supongo que AWS/GCP usa cpuset para el hipervisor, o algo así. ¿Es posible aislar CPU en AWS/GCP? ¿Cómo puedo hacerlo?
Respuesta1
Está utilizando systemd que ya montó cgroups v2 ("unificados"), por lo que no es usted quien administra los grupos de control, sino systemd. Dígale que lo haga a través delCPUAffinity= y opciones relacionadas en la [Manager]sección de un /etc/systemd/system.conf.d/50-my-cpuset-options.confarchivo. Luego puede usar CPUAffinity=(vacío para restablecer, no vacío para agregar) para aquellos archivos unit.service específicos que desea eximir del valor predeterminado global.
Incluso puede usar las API de systemd para modificar transitoriamente (hasta el reinicio) las opciones de recursos en servicios que ya se están ejecutando mediante el systemctl --runtime set-property example.service ExampleOption=Valuecomando. Úselo para confirmar la configuración de cgroup resultante y medir cómo afecta el rendimiento de su sistema. Me imagino que en lugar de valores predeterminados globales, verá una confiabilidad del sistema considerablemente mejor bajo congestión si en lugar de dañar la capacidad del programador para utilizar el 100% de la CPU, mejora todas sus capacidades. Haga coincidir más estrechamente sus prioridades usando Nice=y IOSchedulingClass=en aquellas tareas en segundo plano asíncronas específicas de baja prioridad que desea ejecutar pero que no desea afectar el resto del sistema, pero deje el mazo de afinidad sin usar.
En teoría, servicios públicos comocsetpodría actualizarse para interactuar con dichos administradores del sistema cgroup2 y ofrecer abstracciones efectivamente idénticas a las anteriores mientras se modifican en segundo plano los systemds system.slicey los valores predeterminados de las unidades, peroesta discusión suenacomo si nadie lo hubiera hecho hasta ahora. Y desde eltrozo gigante de C que lo abarca todoofrece un control mucho más rico, bien documentado y posiblemente más versátil de todas las cosas interesantes que el núcleo ha aprendido a hacer, es posible que ya no sea necesario.
Respuesta2
Como mencioné, systemd crea sus propias jerarquías cgroup2 que, según mis necesidades, no funcionan bien con cset.
Agregué lo siguiente al valor GRUB_CMDLINE_LINUX_DEFAULT en /etc/default/grub para deshabilitar este comportamiento en Ubuntu 22.10.
La línea se verá así una vez que hayas terminado:
GRUB_CMDLINE_LINUX_DEFAULT="systemd.unified_cgroup_hierarchy=false <your_other_params>"
Una vez que hayas terminado, deberás ejecutar como root:
update-grub
grub-install
y luego reiniciar. Después de reiniciar, pude proteger con éxito los CCX en mi CPU Ryzen usando CSET, así como migrar todas las tareas del sistema y del usuario.
Aquí hay más referencias a este problema que encontré en caso de que desee obtener más información: https://github.com/systemd/systemd/issues/13477#issuecomment-528113009 https://github.com/lxc/lxd/issues/10441