Impacto de utilização da CPU devido ao parâmetro de kernel de granularidade RHEL6 vs RHEL7

Question

Após os parâmetros do kernel mostrarem comportamentos muito diferentes de R6 a R7 e não conseguimos descobrir o motivo. Qualquer ajuda apreciada.

kernel.sched_min_granularity_ns kernel.sched_wakeup_granularity_ns

Antecedentes:

• Aplicativo já em execução no RHEL6
• Requisito de baixa latência.

• Aplicativo equipado com recurso de robustez, ou seja, quando a latência começa a aumentar mais do que os níveis de limite aceitáveis (predefinidos) ou o uso da CPU é maior que 85%, então ele interrompe o processamento de novas solicitações para evitar sobrecargas.

• Agora estamos tentando implantar no ambiente virtual RHEL7 e não podemos utilizar a CPU na medida do possível no RHEL6. Nós dificilmente alcançamos 55-60% e observamos os picos de latência além do limite aceitável.

Notas:

• A versão do aplicativo é idêntica nos dois casos (R6 / R7).
• O banco de dados e sua configuração também são idênticos
• A configuração de memória e CPU também é idêntica

No R7, estávamos usando o perfil ajustado, que alterou os seguintes parâmetros do kernel, afetando o comportamento: kernel.sched_min_granularity_ns = 10000000 kernel.sched_wakeup_granularity_ns = 15000000

Se alterarmos esses valores para R6 padrão ( kernel.sched_min_granularity_ns = 4000000 kernel.sched_wakeup_granularity_ns = 4000000 ), obteremos o uso do cpu para os níveis R6 (> 85%).

No entanto, quando colocamos os mesmos valores em R6 ( kernel.sched_min_granularity_ns = 10000000 kernel.sched_wakeup_granularity_ns = 15000000 ), não vemos nenhum impacto adverso e a CPU ainda aumenta para 85-90%, como antes. **

Portanto, os valores não padrão dos dois parâmetros acima são R6 & R7 mostra impacto oposto.

Portanto, estamos procurando o motivo pelo qual o mesmo parâmetro se comporta de maneira muito diferente em comparação com o RHEL6 & RHEL7?

Obrigado antecipadamente.

    

Answer 1

Por fim, conseguimos atingir nossa meta de dimensionar o uso da CPU do aplicativo para 80% + no RHEL7. Agora está muito mais perto de como o aplicativo é executado no RHEL6.

A seguir estão as nossas observações e o motivo que levou à nossa conclusão:

"vmstat" showed "runnable" count > total number of CPUs. But at the same time CPU usage was just 50%. Another indicator was the number of "context switches" between RHEL6 & RHEL7. RHEL7 showed lot lesser context switches for the same application load compared to RHEL6.

Isso significa que o processamento não é lento, mas as tarefas executáveis não são atribuídas aos núcleos da CPU. Depois de um pouco de pesquisa, encontramos o parâmetro de kernel "kernel.sched_migration_cost_ns" , que basicamente especifica a quantidade de tempo antes da qual a tarefa executável seria migrada para outra CPU.

kernel.sched_migration_cost

Amount of time after the last execution that a task is considered to be “cache hot” in migration decisions. A “hot” task is less likely to be migrated, so increasing this variable reduces task migrations. The default value is 500000 (ns). If the CPU idle time is higher than expected when there are runnable processes, try reducing this value. If tasks bounce between CPUs or nodes too often, try increasing it.

Diminuir o valor de kernel.sched_migration_cost para cerca de 250 nanossegundos (padrão: 500ns) nos ajuda a acelerar o uso da CPU para 80%.