Alta carga devido a espera de E / S no Ubuntu 12.04 na instância do EC2

Question

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

depois de ler Solução de problemas do Linux, Parte I: Alta carga

Parece que não há problemas com CPU e RAM, e essa carga pode estar relacionada a carga vinculada a E / S usando o comando top que recebi após a saída

Aquiestá97.6%wa,aRAMestálivreenãousaswap.

Aseguirestáasaídadocomandoiostatquemostraquehá89%iowait

ubuntu@ip-my-sys-ubuntu:~$iostatLinux3.2.0-58-virtual(ip-172-31-6-203)02/19/2015_x86_64_(1CPU)avg-cpu:%user%nice%system%iowait%steal%idle3.050.013.6489.503.760.03Device:tpskB_read/skB_wrtn/skB_readkB_wrtnxvdap169.913.81964.37978925247942876

Eutambémuseiiotop,queapósointervalodecorreçãomostra99%deE/S,odiscoescrevecomoobservadorcomo1266KB/s

e

Éruim?comootempoderespostaéreduzido.Oquêestácausandoisto?

EDITSquesãofeitasporoutraspessoas

iftopO/P

12.5kb25.0kb37.5kb50.0kb62.5kb└─────────────────┴──────────────────┴─────────────────┴──────────────────┴──────────────────ip-12-1-1-111.ap-southeast-1.=>115.231.218.1300b2.04kb522b<=0b1.53kb393bip-112-1-1-111.ap-southeast-1.=>62.snat-111-91-22.hns.net.in1.52kb1.52kb1.72kb<=208b208b262bip-112-1-1-111.ap-southeast-1.=>static-mum-120.63.141.177.mtnl.0b480b240b<=0b350b175bip-112-1-1-111.ap-southeast-1.=>ip-112-11-1-1.ap-southeast-1.co0b118b178b<=0b210b292bip-112-1-1-111.ap-southeast-1.=>static-mum-120.63.194.119.mtnl.0b0b240b<=0b0b175bTX:cum:123kBpeak:3.72kbrates:1.67kb2.02kb1.78kbRX:51.5kB4.88kb1.19kb989b918bTOTAL:174kB8.60kb2.86kb2.98kb2.68kb

saídadeiostat-x-k52

ubuntu@ip-111-11-1-111:~$iostat-x-k52Linux3.2.0-58-virtual(ip-111-11-1-111)03/04/2015_x86_64_(1CPU)avg-cpu:%user%nice%system%iowait%steal%idle3.750.014.7422.724.0664.71Device:rrqm/swrqm/sr/sw/srkB/swkB/savgrq-szavgqu-szawaitr_awaitw_awaitsvctm%utilxvdap10.00263.800.42109.427.281572.3628.761.9217.5217.5717.522.3125.39avg-cpu:%user%nice%system%iowait%steal%idle8.970.004.7776.349.920.00Device:rrqm/swrqm/sr/sw/srkB/swkB/savgrq-szavgqu-szawaitr_awaitw_awaitsvctm%utilxvdap10.0035.690.0085.880.00438.9310.22137.551612.710.001612.7111.1195.42

@shodanshokpoint2

iotop -a

    

Answer 1

Sintonize seu serviço mysql para evitar tocar no disco e ficar de olho na fila do postfix, você pode ter muitos e-mails em uma fila sensível à E / S (isto é, itens pequenos com comportamento de leitura aleatório).

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

Consulte a documentação do postfix e restrinja o acesso do relé ao seu MTA.

    

Answer 2

Editado depois de informações adicionais reunidas usando iostat e iotop
Seu disco está 100% carregado enquanto está ficando sem IOPS disponível: de acordo com o iostat, você tem uma constante de 50+ IOPS (85 w / s - 35 mesclados w / s). As instâncias do EC2, especialmente as mais baratas, têm um strong limite na IOPS sustentada (na faixa de 30 a 50 IOPS).

De acordo com a nova saída iotop, tanto o mysql quanto o bounce estão consumindo uma quantidade significativa de IOPS. No entanto, a saída do iotop parece incompleta ou mal ordenada, pelo menos. Você pode executar novamente o "iotop -a" classificando uma vez por IOPS e outra por gravação em 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? Discos EC2 têm regras bastante rígidas para E / S sustentada versus estouro).

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, em algum momento ele não fornece as informações necessárias. Nós precisamos ir mais fundo. Então, siga estes conselhos:

1. Primeiro, precisamos identificar o tipo de E / S sendo processado e o dispositivo de bloqueio afetado.
   Por favor, execute o seguinte comando: iostat -x -k 5 2 . Por favor, reporte os dois conjuntos de resultados.
2. Em seguida, precisamos identificar os processos que esperam por E / S .
   Quando pode usar "top" para isso: inicie-o, pressione shift + f (F), depois w, depois entre, e depois mude + r (R). Os primeiros processos serão os do estado D ou D + (ex .: aguardando disco / rede). Por favor, informe a lista.
3. Use o iotop para mostrar os valores de E / S acumulados para processos .
   Execute iotop -a por aproximadamente um minuto e cole aqui a saída.

Answer 3

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

Veja /var/log/mysql/error.log ou use mysqlcheck para encontrar e reparar dados corrompidos.

    

Answer 4

Como dito acima, é bem provável que sua instância do EC2 venha com um limite de I / O ou talvez tenha um backup em um volume do Amazon EBS Standard que simplesmente não ofereça muito IO. Dê uma olhada nesta esta página - ela descreve os diferentes tipos de volume que a Amazon oferece. p>

Mesmo se você tiver o tipo lento de volume, você ainda deve ser capaz de escrever razoavelmente rápido para ele, mas se sua carga é aleatória por natureza, como parece que pode ser (coisas SQL), você pode querer Atualize a capacidade de IOPS, pois isso geralmente coloca o limite superior no desempenho do SQL.

Então - pelos 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 em isto .

    

Answer 5

O disco pode estar no modo não-DMA. Por favor, verifique o status DMA da unidade. (comando hdparm)

Se não é isso, algo mais pode gerar muitas interrupções. Alguém se lembra daqueles da boa e velha era DOS?