Tenho duas instâncias de 32 vCPU no AWS/GCP. Estou tentando configurar a blindagem da CPU para que as CPUs 0, 1 sejam usadas pelo sistema e as CPUs 2-31 sejam blindadas e usadas apenas explicitamente pelos threads do espaço do usuário.
Informação do sistema:
Distributor ID: Ubuntu
Description: Ubuntu 22.04.1 LTS
Release: 22.04
Codename: jammy
$ cat /proc/filesystems | grep cpuset
nodev cpuset
No entanto, quando tento executar cset shield, recebo um erro relacionado às montagens:
mount: /cpusets: none already mounted on /run/credentials/systemd-sysusers.service.
cset: **> mount of cpuset filesystem failed, do you have permission?
Pesquisei um pouco no código cset e parece que a chamada com falha é uma das
$ sudo mount -t cpuset cpuset /cpusets
mount: /cpusets: cpuset already mounted or mount point busy.
/cpusetsé uma pasta recém-criada e $ cat /proc/mounts | grep cpusetestá vazia - então cpuset não parece estar montado em outro lugar.
Talvez relevante:
$ cat /proc/mounts | grep cgroup
cgroup2 /sys/fs/cgroup cgroup2 rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot 0 0
Meu palpite é que o AWS/GCP usa cpuset para o hipervisor ou algo parecido. É possível isolar cpus no AWS/GCP? Como posso fazer isso?
Responder1
Você está usando o systemd que já montou cgroups v2 ("unificados"), então não é você quem gerencia os grupos de controle - é o systemd. Diga-lhe para fazer isso através doCPUAffinity= e opções relacionadas na [Manager]seção de um /etc/systemd/system.conf.d/50-my-cpuset-options.confarquivo. Você pode então usar CPUAffinity=(vazio para redefinir, não vazio para adicionar) para os arquivos unit.service específicos que deseja isentar do padrão global.
Você pode até usar APIs do systemd para modificar transitoriamente (até a reinicialização) opções de recursos em serviços já em execução por meio do systemctl --runtime set-property example.service ExampleOption=Valuecomando. Use isso para confirmar as configurações resultantes do cgroup e medir como isso afeta o desempenho do seu sistema. Imagino que, em vez de padrões globais, você verá uma confiabilidade mensuravelmente melhor do sistema sob congestionamento se, em vez de prejudicar a capacidade do agendador de utilizar 100% da CPU, você melhorar todas as suas capacidades. Combine mais de perto suas prioridades usando Nice=e IOSchedulingClass=naquelas tarefas assíncronas em segundo plano específicas de baixa prioridade que você deseja executar, mas não deseja impactar o resto do sistema - mas deixe a marreta de afinidade sem uso.
Em teoria, utilitários comocsetpoderia ser atualizado para interagir com esses gerenciadores de sistema cgroup2 e oferecer abstrações efetivamente idênticas a antes enquanto em segundo plano modificava systemds system.slicee padrões de unidade, masessa discussão soacomo se ninguém tivesse feito isso até agora. E desde opedaço gigante de C abrangenteoferece um controle muito mais rico, bem documentado e possivelmente mais versátil de todas as coisas legais que o kernel aprendeu a fazer, pode não haver mais necessidade disso.
Responder2
Como mencionado, o systemd cria suas próprias hierarquias cgroup2 que, com base nas minhas necessidades, não funcionam bem com o cset.
Anexei o seguinte ao valor GRUB_CMDLINE_LINUX_DEFAULT em /etc/default/grub para desabilitar esse comportamento no Ubuntu 22.10.
A linha ficará mais ou menos assim depois que você terminar:
GRUB_CMDLINE_LINUX_DEFAULT="systemd.unified_cgroup_hierarchy=false <your_other_params>"
Depois de terminar, você precisará executar como root:
update-grub
grub-install
e então reinicie. Após a reinicialização, consegui proteger com sucesso os CCX em minha CPU Ryzen usando CSET, bem como migrar todas as tarefas do usuário e do sistema
Aqui estão mais referências a esse problema que encontrei, caso você queira mais informações: https://github.com/systemd/systemd/issues/13477#issuecomment-528113009 https://github.com/lxc/lxd/issues/10441