Atualmente, estou procurando mover nosso sistema do RHEL 5 para o RHEL 6, mas encontrei um problema inesperado com alto uso da CPU nas máquinas do RHEL 6. Parece que isso pode ser devido, pelo menos em parte, ao uso de select para fazer um sono interrompível. Veja um exemplo simples que mostra o comportamento:
#include <sys/select.h>
int main()
{
timeval ts;
for (unsigned int ii=0; ii<10000; ++ii) {
ts.tv_sec = 0;
ts.tv_usec = 1000;
select(0, 0, 0, 0, &ts);
}
return 0;
}
Em uma máquina RHEL 5 ela permanecerá com 0% de uso da CPU, mas no mesmo hardware com RHEL 6 instalado usará cerca de 0,5% da CPU, portanto, quando 30 a 50 programas estiverem sendo executados usando select para executar um sono, consome desnecessariamente uma grande quantidade de CPU.
Eu abri um Bugzilla e tentei rodar o OProfile e ele simplesmente mostra 100% em main para o aplicação e pouco mais de 99% em poll_idle ao olhar para o kernel (eu tenho idle = poll set em minhas opções de grub para que tudo possa ser capturado).
Alguma outra idéia do que eu posso fazer para tentar isolar qual é a causa do maior uso da CPU?
UPDATE: encontrei a ferramenta perf e obtive a seguinte saída:
# Events: 23K cycles
#
# Overhead Command Shared Object Symbol
# ........ ....... ................... ....................................
#
13.11% test_select_sma [kernel.kallsyms] [k] find_busiest_group
5.88% test_select_sma [kernel.kallsyms] [k] schedule
5.00% test_select_sma [kernel.kallsyms] [k] system_call
3.77% test_select_sma [kernel.kallsyms] [k] copy_to_user
3.39% test_select_sma [kernel.kallsyms] [k] update_curr
3.22% test_select_sma ld-2.12.so [.] _dl_sysinfo_int80
2.83% test_select_sma [kernel.kallsyms] [k] native_sched_clock
2.72% test_select_sma [kernel.kallsyms] [k] find_next_bit
2.69% test_select_sma [kernel.kallsyms] [k] cpumask_next_and
2.58% test_select_sma [kernel.kallsyms] [k] native_write_msr_safe
2.47% test_select_sma [kernel.kallsyms] [k] sched_clock_local
2.39% test_select_sma [kernel.kallsyms] [k] read_tsc
2.26% test_select_sma [kernel.kallsyms] [k] do_select
2.13% test_select_sma [kernel.kallsyms] [k] restore_nocheck
Parece que o uso mais alto da CPU é do agendador. Eu também usei o seguinte script bash para lançar 100 destes simultaneamente:
#!/bin/bash
for i in {1..100}
do
./test_select_small &
done
No RHEL 5, o uso da CPU fica próximo de 0%, mas no RHEL 6, há uma quantidade não trivial de uso da CPU no usuário e no sistema. Alguma idéia de como rastrear a verdadeira fonte disso e, esperamos, consertá-lo?
Eu também tentei este teste em uma versão atual do Arch Linux e no Ubuntu 11.10 e vi um comportamento similar, então isso parece ser algum tipo de problema no kernel e não apenas um problema do RHEL.
UPDATE2: Eu hesito um pouco em trazer isso porque sei que é um grande debate, mas eu testei um kernel com os patches do BFS no Ubuntu 11.10 e ele não mostrou o mesmo alto uso de CPU do sistema (cpu do usuário). o uso parecia quase o mesmo).
Existe algum teste que eu possa executar com cada um deles para testar se esse alto uso da CPU é apenas uma diferença na contabilização do uso da CPU que a faz parecer artificialmente alta? Ou se os ciclos reais da CPU estão sendo roubados pelo CFS?
UPDATE3: A análise feita envolvendo essa questão parece indicar que é algo relacionado ao scheduler, então eu criei um UPDATE4: adicionei mais algumas informações à outra pergunta .
UPDATE5: Adicionei alguns resultados à outra pergunta de uma forma mais simples teste que ainda demonstra o problema.