Sim, o problema neste caso foi testar esse recurso. Funciona como esperado. O único problema que eu tive em outra nuvem VM com 2 núcleos. Como não preciso disso, não vou mais pensar nisso. :) Felicidades!
De ontem estou lutando com problemas com contêineres LXC e limitando os recursos da CPU por contêiner. No meu caso, o comando como lxc-cgroup -n srv50 cpu.shares 100 não traz nenhum resultado - os contêineres ainda usam a CPU da mesma forma.
Estou usando o Centos 7 & LXC 1.0.8. Todas as máquinas em que estava verificando tiveram o mesmo efeito: definir cpu.shares não faz nada.
Aqui está a tela systemd-cgtop, da minha VM de 2 núcleos:
Path Tasks %CPU Memory Input/s Output/s
/ 178 199.7 360.8M - -
/lxc - 198.0 16.8M - -
/lxc/srv51 7 99.8 8.4M - -
/lxc/srv50 7 98.2 8.4M - -
/system.slice/NetworkManager.service 2 - - - -
/system.slice/auditd.service 1 - - - -
O contêiner srv50 tem cpu.shares definido como 100, enquanto srv51 definido como 50. Os dois contêineres executam o comando dd if=/dev/urandom | bzip2 -9 >> /dev/null . Eu estava esperando que um contêiner consome 66% e outros 133% de CPU (ou algo parecido), mas ambos usam 100%.
Uma dica. Quando eu estava tentando encontrar qual contêiner usa mais CPU, notei na ferramenta htop que todos os contêineres têm o mesmo cgroup: :name=systemd:/user.slice/user-0.slice/session-1.scope? - não tenho certeza se isso está correto ou não - apenas notei isso.
Limitar a memória funciona, a CPU não.
Acabei de testar os cgroups e não posso definir cpu.share para nenhum processo (movendo-o para algum grupo), por isso é consistente. Cheira como algum switch de kernel ausente.
2: Há um bug no meu exemplo. Para ver a diferença na carga na máquina de 2 núcleos, devemos ter pelo menos dois processos executando 100% por contêiner. De qualquer forma, isso não é um problema.