Atualmente, estou procurando mudar nosso sistema do RHEL 5 para o RHEL 6, mas me deparei com um problema inesperadamente alto no uso da CPU nas máquinas RHEL 6. Parece que isso pode dever-se, pelo menos em parte, ao uso de selectum sono interrompido. Aqui está 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, ele permanecerá com 0% de uso da CPU, mas no mesmo hardware com o RHEL 6 instalado, ele usará cerca de 0,5% da CPU; portanto, quando 30 a 50 programas estiverem sendo executados usando-os selectpara realizar um sono, ele consome um grande quantidade de CPU desnecessariamente.
Abri um Bugzilla e tentei executar o OProfile e ele simplesmente mostra 100% no principal do aplicativo e pouco mais de 99% no poll_idle ao olhar para o kernel (eu tenho idle = poll definido nas minhas opções de grub para que tudo possa ser capturado).
Alguma outra idéia do que 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 maior uso da CPU é do agendador. Também usei o seguinte script bash para iniciar 100 deles simultaneamente:
#!/bin/bash
for i in {1..100}
do
./test_select_small &
done
No RHEL 5, o uso da CPU permanece 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, corrigi-lo?
Eu também tentei esse teste em uma versão atual do Arch Linux e no Ubuntu 11.10 e vi um comportamento semelhante; portanto, isso parece ser algum tipo de problema no kernel e não apenas um problema no RHEL.
UPDATE2: Hesito um pouco em trazer isso à tona porque sei que é um grande debate, mas experimentei um kernel com os patches BFS no Ubuntu 11.10 e ele não mostrou o mesmo alto uso da CPU do sistema (o uso da CPU do usuário parecia 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 contabilidade do uso da CPU que está fazendo com que pareça artificialmente alto? Ou se os ciclos reais da CPU estão sendo roubados pelo CFS?
ATUALIZAÇÃO3: A análise feita com esta pergunta parece indicar que é algo relacionado ao agendador, por isso criei uma nova pergunta para discutir os resultados.
UPDATE4: Adicionei mais algumas informações à outra pergunta .
UPDATE5: adicionei alguns resultados à outra pergunta de um teste mais simples que ainda demonstra o problema.
selectisso?