Carga alta devido à espera de E / S no Ubuntu 12.04 na instância do EC2

Estou usando o servidor Ubuntu 12.04, tendo problemas para encontrar a causa da carga, vi mudanças no tempo de resposta do servidor na semana passada

depois de ler a solução de problemas do Linux, parte I: alta carga

Parece que não há problema com CPU e RAM, e essa carga pode estar relacionada à carga ligada à E / S usando o topcomando que obtive após a saída

Aqui está 97.6%wa, a RAM é gratuita e nenhuma troca é usada.

A seguir, é apresentada a saída do comando iostatque semeia que existe89% iowait

ubuntu@ip-my-sys-ubuntu:~$ iostat
Linux 3.2.0-58-virtual (ip-172-31-6-203)    02/19/2015  _x86_64_    (1 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.05    0.01    3.64   89.50    3.76    0.03

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
xvdap1           69.91         3.81       964.37     978925  247942876

Também usei iotopque, após o intervalo de correção, mostra 99% de E / S, o disco grava o observador como1266 KB/s

e

É ruim? à medida que o tempo de resposta é reduzido. O quê está causando isto?

EDITAS que são solicitadas por outros

iftop O / P

                  12.5kb             25.0kb            37.5kb             50.0kb       62.5kb
└─────────────────┴──────────────────┴─────────────────┴──────────────────┴──────────────────
ip-12-1-1-111.ap-southeast-1.  => 115.231.218.130                      0b   2.04kb   522b
                                 <=                                      0b   1.53kb   393b
ip-112-1-1-111.ap-southeast-1.  => 62.snat-111-91-22.hns.net.in      1.52kb  1.52kb  1.72kb
                                 <=                                    208b    208b    262b
ip-112-1-1-111.ap-southeast-1.  => static-mum-120.63.141.177.mtnl.      0b    480b    240b
                                 <=                                      0b    350b    175b
ip-112-1-1-111.ap-southeast-1.  => ip-112-11-1-1.ap-southeast-1.co      0b    118b    178b
                                 <=                                      0b    210b    292b
ip-112-1-1-111.ap-southeast-1.  => static-mum-120.63.194.119.mtnl.      0b      0b    240b
                                 <=                                      0b      0b    175b

TX:             cum:    123kB   peak:   3.72kb               rates:   1.67kb  2.02kb  1.78kb
RX:                    51.5kB           4.88kb                        1.19kb   989b    918b
TOTAL:                  174kB           8.60kb                        2.86kb  2.98kb  2.68kb

saída de iostat -x -k 5 2

ubuntu@ip-111-11-1-111:~$ iostat -x -k 5 2
Linux 3.2.0-58-virtual (ip-111-11-1-111)        03/04/2015      _x86_64_        (1 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.75    0.01    4.74   22.72    4.06   64.71

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvdap1            0.00   263.80    0.42  109.42     7.28  1572.36    28.76     1.92   17.52   17.57   17.52   2.31  25.39

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8.97    0.00    4.77   76.34    9.92    0.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvdap1            0.00    35.69    0.00   85.88     0.00   438.93    10.22   137.55 1612.71    0.00 1612.71  11.11  95.42

@shodanshok point 2

iotop -a

Sintonize seu serviço mysql para evitar tocar no disco e atente para sua fila de postfix, você pode ter muitos emails em uma fila de E / S sensível (ou seja, adiada, pequenos itens com comportamento aleatório de leitura).

Seu sistema de e-mail foi usado como retransmissão para remetentes de spam.

Dê uma olhada na documentação do postfix e restrinja o acesso de retransmissão ao seu MTA.

Editado após a coleta de informações adicionais usando o iostat e o iotop
Seu disco é 100% carregado, pois fica sem IOPS disponível: conforme o iostat, você tem 50 IOPS constantes (85 w / s - 35 mesclados s / s). As instâncias do EC2, especialmente as mais baratas, têm um forte limite de IOPS sustentado (na faixa de 30 a 50 IOPS).

De acordo com a nova saída iotop, o mysql e o bounce estão consumindo uma quantidade significativa de IOPS. No entanto, a saída do iotop parece não estar completa ou, pelo menos, mal classificada. Você pode executar novamente "iotop -a" classificando uma vez por IOPS e outra por gravação de disco?

Resposta original
Minha aposta: o processo de "rejeição" está emitindo muitas gravações sincronizadas que sufocam o dispositivo de disco virtual oferecido pela Amazon (a propósito, que perfil você está usando? Os discos EC2 têm regras bastante rígidas para E / S sustentada ou burst).

De qualquer forma, identificar o que está queimando a largura de banda de E / S pode ser um pouco difícil às vezes. Embora o iotop seja uma ferramenta muito boa, às vezes não fornece as informações necessárias. Precisamos ir mais fundo. Então, siga estes conselhos:

1. Primeiro, precisamos identificar o tipo de E / S que está sendo processada e o dispositivo de bloco afetado.
   Por favor, execute o seguinte comando: iostat -x -k 5 2. Relate os dois conjuntos de resultados.
2. Então, precisamos identificar os processos à espera de I / O .
   Quando pode usar "top" para isso: inicie-o, pressione Shift + f (F), em seguida, w, digite Enter e, em seguida, Shift + r (R). Os primeiros processos serão aqueles no estado D ou D + (ou seja, aguardando disco / rede). Por favor, reporte a lista.
3. Use iotop para mostrar os valores de E / S acumulados para processos .
   Corra iotop -apor cerca de um minuto e cole aqui a saída.

Um pouco tarde, mas eu tive o mesmo problema em uma máquina semelhante e descobri que o problema era um monte de tabelas MySQL corrompidas. Como algumas dessas tabelas tinham muitos dados, isso produziu muito tempo de espera de E / S.

Examine /var/log/mysql/error.logou use mysqlcheckpara encontrar e reparar dados corrompidos.

Como mencionado acima, é bem provável que sua instância do EC2 venha com um limite de E / S ou talvez tenha um volume Amazon EBS Standard que simplesmente não ofereça muito IO. Veja esta página - ela descreve os diferentes tipos de volume que a Amazon oferece.

Mesmo se você tiver o tipo lento de volume, ainda poderá escrever razoavelmente rápido, mas se sua carga for aleatória por natureza, como parece ser (coisas do SQL), convém atualizar as IOPS capacidade, pois isso geralmente coloca o limite superior no desempenho do SQL.

Portanto, a partir dos seus números, parece que você pode ficar sem IOPS usando o armazenamento padrão. Comprar armazenamento mais rápido não é tão caro. Dê uma olhada nisso .

O disco pode estar no modo não DMA. Verifique o status do DMA da unidade. (comando hdparm)

Caso contrário, outra coisa pode gerar muitas interrupções. Alguém se lembra daqueles da boa e velha era do DOS?