Processos do kernel que comem periodicamente o CPU durante uma carga alta

3

Eu executo um servidor web de produção com 24 núcleos nos quais o trabalho é intensivo em CPU e E / S, mas principalmente em CPU. Meus scripts atrasam a execução quando a carga total da CPU é de aproximadamente 85% ou mais para manter a carga gerenciável. Assim, a CPU nunca está sob maior estresse do que meus scripts sabem que pode manipular.

Agora, meu servidor passa por produção de capacidade máxima em blocos de tempo de até três horas de duração por vez. A maior parte do tempo o trabalho corre bem, mas no meio desse período, muitas vezes a carga do sistema da CPU aumenta dramaticamente. Isso se deve aos processos do kernel "events / x", "migration / x" e "ksoftirqd / x", em que "x" é o número da CPU para esse processo. Eu li que isso indica que o kernel está lutando com tarefas enfileiradas, o que ocorre sob sobrecarregada carga do sistema. No entanto, minha carga de CPU, que é o gargalo principal, é deliberadamente mantida em ~ 85% para evitar esse tipo de problema, como mencionei. Esse uso do kernel do CPU reduz drasticamente a produção e apenas prolonga as tarefas enfileiradas. A parte estranha é que, após cerca de 30 minutos, a carga do sistema desaparecerá, com os processos do kernel diminuindo para zero no uso da CPU, apenas para começar a sobrecarregar a CPU novamente mais tarde. Durante todo esse tempo, a quantidade de trabalho que está sendo alimentada para as CPUs não mudou, e normalmente é tratada muito bem. No entanto, quando esses processos do kernel entram em ação, ele mata completamente a produção.

Aqui está a saída "top -u root" durante um desses eventos. O uso da CPU do usuário é de 49% porque o uso do sistema é de 40%. Normalmente isso deve ser usuário ~ 85%, sistema ~ 5%. No entanto, não há iowait e a média de carga do sistema é 22 (de 24 núcleos), o que é normal.

top - 13:10:49 up 44 days, 20:29, 1 user, load average: 22.87, 22.73, 21.36 Tasks: 622 total, 24 running, 585 sleeping, 0 stopped, 13 zombie Cpu(s): 49.4%us, 40.3%sy, 0.0%ni, 10.1%id, 0.1%wa, 0.0%hi, 0.2%si, 0.0%st Mem: 32728060k total, 31045092k used, 1682968k free, 353768k buffers Swap: 4194300k total, 243136k used, 3951164k free, 19117436k cached

PID EXP RI DO USUÁRIO VIDEO SHR S% CPU% MEM TIME + COMMAND    51 RT de raiz 0 0 0 0 S 11,1 0,0 436: 03,06 migração / 12   100 raiz 20 0 0 0 0 S 9,5 0,0 49: 19,45 eventos / 1   114 raiz 20 0 0 0 0 S 5,9 0,0 48: 14,75 eventos / 15     3 RT raiz 0 0 0 0 S 4,3 0,0 517: 58,05 migração / 0   112 raiz 20 0 0 0 0 S 3,6 0,0 42: 00,54 eventos / 13    27 raiz RT 0 0 0 0 S 2,3 0,0 200: 59,58 migração / 6  8149 raiz 20 0 165m 7732 3928 S 2.3 0.0 0: 00.07 exim    15 raiz RT 0 0 0 0 S 2,0 0,0 450: 05,62 migração / 3    39 RT de raiz 0 0 0 0 S 2,0 0,0 178: 08,17 migração / 9   113 raiz 20 0 0 0 0 S 1,6 0,0 44: 00,04 eventos / 14   178 raiz 20 0 0 0 0 R 1,6 0,0 53: 27,57 kacpid    63 RT de raiz 0 0 0 0 S 1,3 0,0 439: 11,96 migração / 15    81 raiz 20 0 0 0 0 S 1,0 0,0 17: 14,83 ksoftirqd / 19   104 raiz 20 0 0 0 0 S 1,0 0,0 44: 58,55 eventos / 5   115 raiz 20 0 0 0 0 S 1,0 0,0 47: 18,46 eventos / 16     9 raiz 20 0 0 0 0 S 0,7 0,0 13: 56,20 ksoftirqd / 1    25 raiz 20 0 0 0 0 S 0,7 0,0 12: 46,52 ksoftirqd / 5    57 raiz 20 0 0 0 0 S 0,7 1 11: 12,62 ksoftirqd / 13    75 RT raiz 0 0 0 0 S 0,7 0,0 181: 00,24 migração / 18   118 raiz 20 0 0 0 0 S 0,7 0,0 30: 13,06 eventos / 19 10497 raiz 20 0 77964 6244 4096 S 0,7 0,0 17: 40,25 httpd

Há alguma explicação potencial para o comportamento desses processos quando a carga da CPU é estritamente regulada para ser gerenciável? A memória não é um problema, pois o uso de buffers / cache nunca é superior a 30% da capacidade do sistema. Ao pesquisar na web, todo mundo culpa a sobrecarga do sistema, mas o comportamento do meu servidor não sugere que os recursos usados causem esse bloqueio.

Qualquer sugestão seria apreciada.

EDIT: Eu postei o que parece ser a solução na seção de respostas.

    
por meridionaljet 11.03.2015 / 19:25

3 respostas

3

Parece que os processos do kernel podem estar roubando o tempo da CPU durante as transferências para / de swap. As configurações de cache do servidor foram, de alguma forma, redefinidas sem o meu conhecimento, definindo swappiness para 60. Na saída de "sar -W", os hang-ups pareciam coincidir com períodos de alta carga durante os quais pswpin / se pswpout / s eram grandes ( superior a 2,00 ou mais, às vezes até 15,00). Depois de configurar o swappiness para 1, não encontrei os mesmos problemas dos processos do kernel, e o sar -W mostra valores próximos de zero em todos os momentos. Em resumo, parece que a troca agressiva durante a alta carga com grandes transferências de memória estava sobrecarregando o sistema durante períodos de grande e rápida demanda por recursos.

    
por 12.03.2015 / 20:11
1

Eu acompanhei problemas com o processo de migração do kernel aqui . Parece que o kernel do linux anterior a 3.6.11 é afetado. O link mostra um sintoma semelhante em que o processo de migração demora muito tempo da CPU. Se possível, você pode querer atualizar o kernel para ver se o problema persiste.

    
por 11.03.2015 / 21:11
0

migration é o processo do kernel que lida com processos em movimento de uma CPU para outra.

Portanto, por algum motivo, o seu planejador Linux decide que os processos precisam ser movidos para outra CPU, e o processo de migração consome o tempo da CPU.

Você pode tentar fixar processos em CPUs específicas ou tentar agendadores diferentes com seu kernel. Talvez algum outro programador não esteja tão ansioso em migrar processos para outras CPUs.

    
por 11.03.2015 / 20:31