Eu tenho dois sistemas Linux de núcleo duplo instalados usando cgroups Linux com kernels relativamente recentes; um está executando o Debian Squeeze, o outro Ubuntu 11.04 Natty Narwhal. Eu consegui o balanceamento de carga da CPU com o cgroups trabalhando um pouco melhor no sistema Debian, apesar de seu kernel mais antigo. Mas isso não é adequado para tudo, e a singularidade específica que estou perguntando aqui acontece nos dois sistemas.
Se você ler Gerenciamento de Recursos no Linux com Grupos de Controle , fornece um exemplo mostrando como reproduzir o problema. Aqui está a versão do Ubuntu (execute isso como root):
cd /sys/fs/cgroup/cpu
[On Debian Squeeze start at /mnt/cgroups/cpu instead]
mkdir low high
echo 512 > low/cpu.shares
echo 2048 > high/cpu.shares
yes low > /dev/null &
echo $! > low/tasks
yes high > /dev/null &
echo $! > high/tasks
ps -C yes -opid,%cpu,psr,args
[repeat that a few times]
killall -9 yes
Eu esperava que o processo "alto" fosse alocado mais tempo que o processo "baixo"; o que realmente acontece com este caso de teste é sempre mais assim:
root@black:/sys/fs/cgroup/cpu# ps -C yes -opid,%cpu,psr,args
PID %CPU PSR COMMAND
3105 88.3 1 yes low
3106 94.5 0 yes high
Onde os tempos são quase iguais. Aqui está a minha pergunta: por que isso está acontecendo?
Na apresentação, esse problema é mostrado desaparecendo, fixando cada processo na mesma CPU; linhas adicionais para testar se:
taskset -c 1 yes high > /dev/null &
echo $! > high/tasks
taskset -c 1 yes low > /dev/null &
echo $! > low/tasks
ps -C yes -opid,%cpu,psr,args
[later, rinse, repeat]
killall -9 yes
O resultado é o que eu esperava ver o tempo todo: o processo "alto" obtendo uma porcentagem muito maior da CPU:
root@black:/sys/fs/cgroup/cpu# ps -C yes -opid,%cpu,psr,args
PID %CPU PSR COMMAND
3128 83.3 1 yes high
3129 20.7 1 yes low
Explicar por que isso funciona seria um passo útil para descobrir por que o anterior também não.
fonte
Respostas:
Eu recebi uma explicação inicial sobre esse caso de teste de Stefan Seyfried, que escreveu o artigo em que este exemplo foi retirado. O problema aqui é que as partes do cgroups do planejador de CPU sempre visam manter ocupada a CPU disponível; ele nunca impõe um limite rígido se tudo couber de uma só vez.
No caso de dois processos (alto e baixo aqui) serem executados em> = 2 núcleos, ele continuará alto em um núcleo e baixo no outro. Ambos serão executados o tempo todo, com quase 100% de uso, porque podem fazê-lo sem atingir a situação em que o agendador não lhes dá tempo suficiente na CPU. A programação do cpu.share só acontece se houver uma falta.
No segundo caso, ambos os processos são fixados na mesma CPU. Então a lógica de compartilhamento da CPU precisa fazer algo útil com os números relativos de cpu.shares para equilibrá-los, e isso é o que se espera.
É provável que os limites rígidos de uso da CPU apareçam até depois que o patch do CFS Bandwidth Control for atingido . Nesse ponto, pode ser possível obter algo mais parecido com o que eu estava esperando.
fonte