Estou tentando entender se a configuração de cpu.cpu_quota_us em cpu cgroup subsytem tem algum impacto no desempenho do aplicativo. Basicamente, reduzindo a cota de CPU, mas aumentando o número de CPUs de modo que as CPUs "efetivas" ainda sejam as mesmas, isso impactaria o aplicativo? Por exemplo, a configuração de cota de 100% de 4 CPUs é igual à configuração de cota de 50% de 8 CPUs?
Eu sei que isso depende muito do design do aplicativo e se o seu cpu ou io está vinculado. Aqui, estou preocupado apenas com aplicativos intensivos da CPU.
Meu esforço:
Eu escrevi uma simples aplicação C disponível aqui link .
Este programa cria encadeamentos 'N'. Cada thread inicia o cálculo dos números primos, começando entre o número 'n' e o 1000000. O número inicial 'n' é diferente para cada thread. Depois de computar 100 números primos, o encadeamento fica suspenso por um período fixo de tempo. Uma vez que o segmento atinge 1000000, ele começa de 2. No final, o thread principal exibe o número cumulativo de primos calculados por cada thread. Eu trato isso como o "throughput" deste aplicativo de amostra.
Eu executei este programa sob as seguintes configurações:
Eu desabilitei os hyperthreads definindo / sys / devices / system / cpu / cpu / online 'para 0.
Para cada configuração, variei o número de threads de 4 para 32. A seguir estão os resultados da "taxa de transferência" gerada pelo programa de amostra. Os números são uma média de 10 iterações.
threads cpu4quota100 cpu8quota50 4 66229.5 66079.4 8 128129 129768 16 189247 134882 24 188238 98917.8 32 176236 87252.5
Observe que há grande diferença no rendimento entre dois casos do encadeamento 16 em diante. Para 24 e 32 encadeamentos, a taxa de transferência caiu consideravelmente para o caso "cpu8quota50".
Também tenho os resultados perf stat para essas execuções. Percebi que cpu-migrations relatado por perf varia bastante entre essas duas configurações. Aqui está a comparação
threads cpu4quota100 cpu8quota50 4 9.6 11.2 8 3252.2 37.9 16 2956.2 4490.5 24 472.6 2347 32 118.3 1727.2
Os números para os threads 4, 8 e 16 fazem sentido, mas não consigo compreender os números para o thread 24 e 32 para o caso "cpu4quota100", que são muito menos do que o caso do thread 16.
Alguém pode fornecer explicações para esses resultados? Além disso, o "cpu-migration" tem algum impacto no desempenho do aplicativo?
Desculpe pelo longo post!
Editar 1:
Eu atualizei meu script para executar o programa de exemplo acima mencionado para cronometrar a execução usando o comando time para ver se há alguma diferença entre os casos "cpu4quota100" e "cpu8quota50".
Eu fiz a corrida para 32 segmentos apenas, e estes são os resultados:
time cpu4quota100 cpu8quota50 user 119.956 secs 120.076 secs sys 0.001 secs 0.009 secs CPU 386.2% 386.5%
Portanto, não há muita diferença em user e sys tempo nos dois casos, mas a "taxa de transferência" é duas vezes em cpu4quota100 caso comparado a cpu8quota50 caso.
Editar 2:
Parece que mudar o regulador do kernel para a frequência da CPU ajudou a melhorar o rendimento do cpu8quota50 case.
Os números anteriores foram obtidos quando o regulador de frequência "powersave" estava em uso. Com "powersave" a freqüência da CPU dos núcleos no caso de cpu4quota100 foi atingida no máximo, mas para cpu8quota50 foi muito menor.
No entanto, depois de alterar o regulador de frequência para "desempenho", a frequência da CPU no caso de cpu8quota50 também estava próxima ao máximo.
Para 32 threads em execução com "performance" como regulador de frequência, recebo os seguintes números:
threads cpu4quota100 cpu8quota50 32 175804 163831
Então a diferença agora caiu de quase 50% para apenas 6,8%.
Mas é interessante notar a diferença de comportamento do governador "powersave" nos dois casos mencionados acima. Não tenho certeza se está funcionando como esperado no caso cpu8quota50 .
Tags performance cgroups