Baixa carga média, mas alta porcentagem de usuários e% de uso da CPU do sistema

Question

Resumida pergunta:

• Por que vemos um conjunto de servidores piorando significativamente com o mesmo banco de dados e carga de trabalho que os outros? Outros sintomas além do tempo de execução mais longo são a baixa (quase zero) média de carga, o alto uso de CPU e, especificamente, o alto% de uso do sistema.

Descrição longa: Eu tenho vários servidores localizados em um parceiro de hospedagem, executando o MySQL 5.1.67 e 5.1.73, onde observamos problemas de desempenho durante o horário de pico.

O que vemos é a média de carga caindo do nível normal para quase 0 (0,10-0,20), talvez seja melhor descrevê-la com essa imagem da New Relic

Eu posso reproduzir o problema com uma carga de trabalho capturada (e um despejo do banco de dados) se eu o executar paralelamente em nossos servidores de Teste e Produção, mas não em outros.

Eu configurei uma instância do Amazon com o mesmo my.cnf do Testing (detalhes no final do post) e também tentei em outro servidor Linux (contêiner LXC) que tenho disponível e até mesmo no meu PC desktop. O tempo de execução em Teste e Produção é de 4 minutos, em que todos os outros demoram cerca de 1 min 30 segundos e não mostram esse comportamento em que a média de carga é baixa, mas% user e% system são altos.

O Vmstat mostra uma fila de execução alta e um número alto de comutadores de contexto enquanto a carga de trabalho é executada, mas apenas nas máquinas problemáticas, o sar não mostra iowait:

Teste:

$ ./workload.sh & vmstat 1 10 -w
procs -------------------memory------------------ ---swap-- -----io---- --system-- -----cpu-------
 r  b       swpd       free       buff      cache   si   so    bi    bo   in   cs  us sy  id wa st
1  0     168896    3218240     447004   12226164    0    0     9    75   19   12   3  1  97  0  0
32  0     168896    3129304     447004   12226204    0    0    32     0 22669 357979  49 23  27      0  0
29  0     168896    3129112     447004   12226212    0    0     0    40 23365 422537  49 26  25  0  0
14  0     168896    3126188     447004   12226232    0    0     0    52 22386 456626  43 27  30  0  0
29  0     168896    3130980     447012   12226204    0    0     0    68 23028 459332  45 27  29  0  0
24  0     168896    3125212     447020   12239788    0    0     0    96 22968 367447  49 24  27  0  0
27  0     168896    3104804     447020   12259820    0    0     0    68 22830 406129  50 28  22  0  0
30  0     168896    3081740     447020   12280300    0    0     0     0 22493 423641  49 29  22  0  0

top on Testing:
$ top
top - 19:49:22 up 1 day,  1:15,  5 users,  load average: 0.08, 0.10, 0.09
Tasks: 607 total,   1 running, 606 sleeping,   0 stopped,   0 zombie
Cpu(s): 43.7%us, 18.0%sy,  0.0%ni, 38.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st

sar on Testing:
08:11:04 PM     CPU     %user     %nice   %system   %iowait    %steal     %idle
08:11:05 PM     all     51.08      0.00     24.37      0.00      0.00     24.54
08:11:06 PM     all     47.14      0.00     26.15      0.00      0.00     26.71

Amazon:

$ ./workload.sh & vmstat 1 10 -w
[1] 10472
procs -------------------memory------------------ ---swap-- -----io---- --system-- -----cpu-------
 r  b       swpd       free       buff      cache   si   so    bi    bo   in   cs  us sy  id wa st
 6  0          0   14133876      30316      90372    0    0     1     1   58   79   2  0  98  0  0
14  0          0   14090268      30316      95972    0    0     0     0 16866 27910  88 10   3  0  0
34  0          0   13910708      30324      90372    0    0     0   192 13934 25824  86  9   5  0  0
 1  0          0   14079724      30332      90372    0    0     0   228 10041 8075  31  2  67  0  0
 2  0          0   14102296      30332      90372    0    0     0     0 10129 7601  14  2  84  0  0
28  0          0   14095320      30332      92020    0    0     0     0 19820 27951  76  8  16  0  0
32  0          0   13940612      30340      91256    0    0     0   144 20896 26666  83 11   6  0  0
 1  0          0   14068780      30348      90372    0    0     0   204 13971 13457  53  4  42  0  0
26  0          0   14068696      30356      92816    0    0     0    56 18661 24165  65  8  26  0  0
16  0          0   13997072      30372     101740    0    0     0   288 14984 23034  63  9  26  2  0

top on Amazon:

]$ top
top - 13:51:09 up  6:12,  2 users,  load average: 6.72, 3.73, 1.69
Tasks: 256 total,   6 running, 250 sleeping,   0 stopped,   0 zombie
Cpu(s): 68.8%us,  7.5%sy,  0.0%ni, 23.6%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st

Servidores:

• Produção: MySQL slave (somente leitura) executando 5.1.67, RedHat 6.4. CPU Xeon (R) de 2 x 6 núcleos E5-2630L 0 @ 2.00GHz com HyperThreading, 192 GB de ram (128 GB innodb_buffer)

• Teste: MySQL 5.1.73, RedHat 6.5 (atualizado recentemente para ver se isso resolveria o problema). CPU Xeon (R) de 2 x 6 núcleos E5-2630L 0 @ 2.00GHz com HyperThreading, 32 GB de RAM (4192M innodb_buffer)

Além disso, temos o seguinte, onde não vejo o problema e que executa a carga de trabalho em 1m30s, em comparação com 4min nos dois itens acima:

• Amazon: MySQL 5.1.73, c4x2large RedHat 6.5 - configurado com sysctl.conf e my.cnf do servidor de teste.

• LXC: MySQL 5.1.73, CentOS6, my.cnf do teste

• Minha área de trabalho: MariaDB 5.5, Ubuntu, i7 4 core.

Answer 1

Acho que sei em que você está chegando. Aqui está um cenário que pode chegar a uma maior utilização da CPU e, ao mesmo tempo, ter uma carga média menor. Embora, honestamente, ter CPU a 50% deva menos implicar uma carga de 0,5. Então, algo está errado em um nível fora do seu controle.

Dito isso, considere o seguinte:

1) O servidor virtual tem um esquema de alocação de CPU de burst / limite semelhante às microinstâncias do Amazon EC2.

2) Seu aplicativo usa CPU suficiente para usar o burst e é acelerado.

3) Esse acelerador aumenta a porcentagem de CPU percebida usada e, ao mesmo tempo, reduz o rendimento real do aplicativo.

4) O rendimento reduzido do aplicativo significa menos atividades relacionadas (subprocessos, gravações de disco, ...) que significam menos carga criada em geral.