Eu também adicionaria as três ferramentas a seguir ao mix. Supondo que você os tenha instalado, caso contrário, você deve ser capaz de instalá-los através de qualquer repositório fornecido para a sua instância do ec2.
A alta carga provavelmente está sendo causada por E / S de disco ou rede, então eu focará nessas duas áreas para começar.
nethogs
A rede seria minha primeira suspeita, para diagnosticar ainda mais, eu usaria nethogs para ver quais processos estão causando isso.
Exemplo
Determine sua interface de rede, para que você possa dizer a nethogs qual deles assistir.
$ ip link show up | awk '/UP/ {print $2}'
lo:
em1:
wlp3s0:
virbr0:
No meu caso, vou assistir ao meu dispositivo sem fio, wlp3s0 .
$ sudo nethogs wlp3s0
NetHogs version 0.8.0
PID USER PROGRAM DEV SENT RECEIVED
2151 saml /opt/google/chrome/chrome wlp3s0 2.117 2.715 KB/sec
3569 saml ..4/thunderbird/thunderbird wlp3s0 0.441 1.496 KB/sec
3144 saml ..aml/.dropbox-dist/dropbox wlp3s0 0.081 0.061 KB/sec
3383 saml pidgin wlp3s0 0.026 0.056 KB/sec
4025 saml ssh wlp3s0 0.000 0.000 KB/sec
? root unknown TCP 0.000 0.000 KB/sec
TOTAL 2.665 4.327 KB/sec
Olhando para a saída, podemos ver que chrome está usando a maior parte da minha largura de banda.
iftop
Você pode ver se o tráfego está vindo de um conjunto específico de sites usando iftop .
195kb 391kb 586kb 781kb 977kb
└───────────────┴───────────────┴───────────────┴───────────────┴───────────────
greeneggs.bubba.net => stackoverflow.com 4.68kb 10.2kb 8.24kb
<= 33.5kb 14.7kb 21.4kb
greeneggs.bubba.net => ord08s12-in-f8.1e100.net 0b 3.90kb 3.99kb
<= 0b 3.61kb 3.72kb
greeneggs.bubba.net => ord08s10-in-f16.1e100.net 5.05kb 4.10kb 5.83kb
<= 2.43kb 2.39kb 2.79kb
greeneggs.bubba.net => stackoverflow.com 1.32kb 3.34kb 4.73kb
<= 1.30kb 1.60kb 2.30kb
greeneggs.bubba.net => cpe-67-253-170-83.rochest 0b 2.19kb 760b
<= 0b 2.60kb 862b
greeneggs.bubba.net => pop1.biz.mail.vip.ne1.yah 5.87kb 1.17kb 301b
<= 17.4kb 3.47kb 889b
greeneggs.bubba.net => 190.93.247.58 480b 2.04kb 2.66kb
<= 0b 1.34kb 1.80kb
greeneggs.bubba.net => ig-in-f95.1e100.net 448b 1.02kb 1.27kb
<= 240b 437b 534b
greeneggs.bubba.net => ord08s12-in-f2.1e100.net 896b 346b 218b
<= 480b 221b 124b
────────────────────────────────────────────────────────────────────────────────
TX: cum: 652kB peak: 85.2kb rates: 20.6kb 29.3kb 30.1kb
RX: 883kB 161kb 57.9kb 31.4kb 40.6kb
TOTAL: 1.50MB 241kb 78.5kb 60.7kb 70.7kb
fatrace
Você pode usar a ferramenta fatrace para ver quais processos estão causando acessos ao HDD.
$ sudo fatrace
pickup(4910): O /var/spool/postfix/maildrop
pickup(4910): C /var/spool/postfix/maildrop
sshd(4927): CO /etc/group
sshd(4927): CO /etc/passwd
sshd(4927): RCO /var/log/lastlog
sshd(4927): CWO /var/log/wtmp
sshd(4927): CWO /var/log/lastlog
sshd(6808): RO /bin/dash
sshd(6808): RO /lib/x86_64-linux-gnu/ld-2.15.so
sh(6808): R /lib/x86_64-linux-gnu/ld-2.15.so
sh(6808): O /etc/ld.so.cache
sh(6808): O /lib/x86_64-linux-gnu/libc-2.15.so
O que mais?
Eu daria uma olhada neste Unix & Linux Q & A que eu respondi um tempo atrás para mais ferramentas para tentar. É intitulado: Determinando o arquivo específico responsável pela alta E / S .
Perguntas de seguimento dos comentários
Q1: Does bandwidth shown by nethogs count against IO requests in AWS? I thought that would fall under 'data transfer' which is a separate category. In iotop the biggest percentage usage was root and a command called 'kswapd0'. mysqld had the biggest disk write usage and httpd had the most disk read
Eu não tenho ideia de como isso realmente é rastreado pela Amazon. Esses valores são da perspectiva do host da VM, portanto, eles podem não se correlacionar nem remotamente ao que a Amazon está rastreando o uso de suas VMs de sua perspectiva.
A propósito, esse kswapd0 é provavelmente a origem de suas solicitações de IO alto. Isso está acontecendo porque, muito provavelmente, sua VM não tem RAM suficiente para satisfazer o tamanho / uso dos aplicativos que você está executando na VM. Então, para tentar atender a necessidade que seu sistema está usando para usar o swap.
Você pode confirmar isso um pouco mais por meio do comando free .
Exemplo
$ free -ht
total used free shared buffers cached
Mem: 7.6G 5.5G 2.1G 0B 446M 2.5G
-/+ buffers/cache: 2.6G 5.0G
Swap: 7.6G 40K 7.6G
Total: 15G 5.5G 9.7G
Isso mostra quanto de RAM & swap estão em uso pelo seu sistema.
Q2: Oh and one follow up question. How does MB or KB of disk read/write in iotop relate to number of IO requests? For example if mysqld wrote 20 M to disk, is there any easy way to know how many IO requests that generated?
Não há realmente nenhuma correlação que eu saiba em relação ao número de leitura / gravação de E / S e à quantidade agregada de dados lidos / gravados no disco.
Considerando que você está usando o AWS, suas leituras / gravações em disco podem muito bem nem estar em um disco local, elas podem ser armazenadas na rede (SoE - também conhecido como SCSI sobre Ethernet, por exemplo).
Sua VM ficaria completamente alheia a isso, já que a configuração de SoE provavelmente seria feita no nível do host e, em seguida, exposta como discos a qualquer VM em execução no host.