SobreAmazon Web ServicesEstou usando umt2.small EC2por exemplo, como um VPS que atende alguns sites em uma pilha LAMP (PHP). Acabei de receber uma conta que quase triplica minha conta habitual. Eu vejo que meuO uso de solicitações de E/S foi extraordinariamente alto. Entrei no servidor e percebi que o disco estava cheio. Removi vários arquivos e logs não críticos e o disco (EBS) agora está com <60% da capacidade, mas gostaria de verificar duas coisas.
- Como posso saber se o grande número de solicitações de E/S foi devido ao enchimento do disco?
- Como posso saber se ainda estou gravando solicitações de E/S?
Eu não tinha o específico da AWSCloudWatchserviço de monitoramento ativado, então provavelmente não receberei uma resposta para o número 1, mas qualquer conselho seria apreciado.
Em relação ao nº 2, usei os dois métodos mencionados emesta postagem do blogpara determinar minha taxa de E/S, e parece que ela é muito, muito alta. Aqui estão algumas estatísticas do servidor:
$ iostat
Linux 3.13.0-45-generic (dysphoria) 2015-10-08 _x86_64_ (1 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
2.74 0.01 0.69 16.83 0.43 79.30
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
xvda 170.08 10039.29 32.52 843300857 2731428
xvdf 0.01 0.02 0.00 1308 0
$ cat /proc/diskstats
1 0 ram0 0 0 0 0 0 0 0 0 0 0 0
1 1 ram1 0 0 0 0 0 0 0 0 0 0 0
1 2 ram2 0 0 0 0 0 0 0 0 0 0 0
1 3 ram3 0 0 0 0 0 0 0 0 0 0 0
1 4 ram4 0 0 0 0 0 0 0 0 0 0 0
1 5 ram5 0 0 0 0 0 0 0 0 0 0 0
1 6 ram6 0 0 0 0 0 0 0 0 0 0 0
1 7 ram7 0 0 0 0 0 0 0 0 0 0 0
1 8 ram8 0 0 0 0 0 0 0 0 0 0 0
1 9 ram9 0 0 0 0 0 0 0 0 0 0 0
1 10 ram10 0 0 0 0 0 0 0 0 0 0 0
1 11 ram11 0 0 0 0 0 0 0 0 0 0 0
1 12 ram12 0 0 0 0 0 0 0 0 0 0 0
1 13 ram13 0 0 0 0 0 0 0 0 0 0 0
1 14 ram14 0 0 0 0 0 0 0 0 0 0 0
1 15 ram15 0 0 0 0 0 0 0 0 0 0 0
7 0 loop0 0 0 0 0 0 0 0 0 0 0 0
7 1 loop1 0 0 0 0 0 0 0 0 0 0 0
7 2 loop2 0 0 0 0 0 0 0 0 0 0 0
7 3 loop3 0 0 0 0 0 0 0 0 0 0 0
7 4 loop4 0 0 0 0 0 0 0 0 0 0 0
7 5 loop5 0 0 0 0 0 0 0 0 0 0 0
7 6 loop6 0 0 0 0 0 0 0 0 0 0 0
7 7 loop7 0 0 0 0 0 0 0 0 0 0 0
202 0 xvda 14198708 1225 1686588426 26715600 87579 51756 5461696 11290600 0 16654328 38003076
202 1 xvda1 14198527 1203 1686586802 26715376 87579 51756 5461696 11290600 0 16654236 38002848
202 80 xvdf 447 6 2616 288 0 0 0 0 0 288 288
$ free -m
total used free shared buffers cached
Mem: 2000 1910 89 6 6 1216
-/+ buffers/cache: 688 1312
Swap: 0 0 0
Embora as informações acima tenham sido obtidas logo após a inicialização, o iostatrelatório mostra um TPS inicial na faixa de 50 a 80, mesmo depois de o sistema estar funcionando por várias horas. O servidor atende cerca de 20 sites, dos quais apenas três recebem mais do que alguns acessos por dia. São da ordem de algumas centenas de visitantes por dia.O servidor e os sites permaneceram nesta configuração durante anos sem problemas.Somente recentemente a E/S começou a aumentar, sem nenhuma alteração correspondente no código, na configuração do servidor ou na carga do site.
Observe que esta pergunta foi feita originalmente emo Fórum Oficial da Amazon Web Servicesno entanto, ninguém parecia ter sido capaz de ajudar lá. Talvez a questão seja muito geral para esse fórum.
Responder1
Há informações importantes na página de manual do iostat que, se não forem compreendidas, podem levar a um mal-entendido dos dados apresentados.
O primeiro relatório gerado pelo comando iostat fornece estatísticas relativas ao tempo desde que o sistema foi inicializado. Cada relatório subsequente cobre o tempo desde o relatório anterior. Todas as estatísticas são relatadas sempre que o comando iostat é executado.
Portanto, seu iostat simples acima relata valores coletados desde que o sistema foi iniciado.
É mais normal executar o iostst com um intervalo e descartar o primeiro conjunto de estatísticas, por exemplo
iostat 5
isso reportará as estatísticas relevantes a cada 5 segundos.
Depois de coletar os dados corretos, você poderá entender melhor a situação.
Dê uma olhada nono topocomando. Em particular, executá-lo com privilégio e seleção dativará as estatísticas de io do disco por thread.