Estamos tendo um problema estranho na nossa infraestrutura Ubuntu 10.04 KVM, onde periodicamente, um dos dois servidores web vm surta, com carga persistentemente alta, mesmo se reiniciarmos os aplicativos. (a única coisa que usa quaisquer recursos significativos do sistema dentro da vm) Se pararmos o daemon do servidor da web completamente, o carregamento cai, mas ele volta para um nível alto quando o iniciamos novamente. Uma reinicialização do convidado vm limpa o problema e ele será executado corretamente por vários dias até o problema retornar.
Recentemente, instalamos o "perf" no hypervisor e notamos que durante o período de carga alta, a função do kernel "__ticket_spinlock" está usando uma grande porcentagem (30-60%) de CPU, comparado a menos de 1% durante o normal Operação. A reinicialização da VM com a carga alta limpa isso. Fazendo algumas pesquisas sobre o entendimento de spinlocks e spinlocks de tickets, criamos a hipótese de que o vm que está com carga alta está esperando por um bloqueio mantido por algum outro vm e, por algum motivo, não o obtém.
Descobrimos uma diferença (entre muitas) entre os hipervisores que têm esse problema e os do CentOS de uma implantação anterior que são configurados da mesma forma, mas não. O kernel para o hypervisor Ubuntu 10.04 é compilado usando um IOScheduler padrão (prazo) diferente e o preempt_voluntary está desativado. Nós sincronizamos essas configurações entre os dois sites e estamos aguardando para ver se a vm no hypervisor atualizado enlouquece novamente.
** Edit: We were never able to find the root cause, but since the migration to Ubuntu 14.04, we have not seen the problem again.
Existe alguma maneira de detectar qual dispositivo um processo do Linux está esperando, quando está em um spinlock de spinlock / ticket? Existe alguma maneira de detectar o que o processo Linux tem um bloqueio em um determinado dispositivo?