Além do iostat , você também deve considerar em cima ( link ) para identificar gargalos não-cpu.
Eu faço o login em um servidor linux (instalado como uma máquina virtual) usando um cliente ssh gráfico (securessh). Este servidor executa um servidor tomcat5.5 onde nexus está instalado.
Quando eu digito comandos ou excluo / copio de arquivos pequenos (em torno de 5-6 MB), o shell leva muito tempo para responder (de 10 segundos a quase um minuto). Eu tentei executar top para ver se algum processo usa muito tempo de memória / cpu:
top - 13:34:41 up 86 days, 16:04, 1 user, load average: 2.13, 0.99, 1.94
Tasks: 63 total, 1 running, 62 sleeping, 0 stopped, 0 zombie
Cpu(s): 2.0%us, 1.5%sy, 0.0%ni, 96.2%id, 0.2%wa, 0.0%hi, 0.1%si, 0.0%st
Mem: 3896416k total, 3097824k used, 798592k free, 167180k buffers
Swap: 915664k total, 84k used, 915580k free, 2409236k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
20436 tomcat55 20 0 359m 217m 13m S 18 5.7 2713:04 jsvc
Apenas o usuário tomcat55 usa uma quantidade significativa de recursos. Com base na saída acima parece que este usuário gasta apenas 5,7% da mem e apenas 5,7% da cpu. Estou interpretando mal a saída de top ? Por que a máquina está funcionando tão mal se a CPU e a memória são tão subutilizadas?
Editar : tentei agora executar em cima e obter:
ATOP - repository 2011/09/20 16:08:48 10 seconds elapsed
PRC | sys 0.17s | user 0.03s | #proc 64 | #zombie 0 | #exit 4 |
CPU | sys 2% | user 1% | irq 0% | idle 198% | wait 0% |
cpu | sys 1% | user 1% | irq 0% | idle 98% | cpu001 w 0% |
cpu | sys 0% | user 0% | irq 0% | idle 99% | cpu000 w 0% |
CPL | avg1 0.05 | avg5 0.92 | avg15 1.29 | csw 976 | intr 61 |
MEM | tot 3.7G | free 656.7M | cache 2.4G | buff 170.9M | slab 241.3M |
SWP | tot 894.2M | free 894.1M | | vmcom 781.9M | vmlim 2.7G |
DSK | sda | busy 0% | read 0 | write 9 | avio 0 ms |
NET | transport | tcpi 18 | tcpo 26 | udpi 0 | udpo 0 |
NET | network | ipi 22 | ipo 26 | ipfrw 0 | deliv 22 |
NET | eth1 0% | pcki 34 | pcko 26 | si 2 Kbps | so 11 Kbps |
PID SYSCPU USRCPU VGROW RGROW RDDSK WRDSK ST EXC S CPU CMD 1/1
4687 0.06s 0.02s 0K 0K - - NE 0 E 1% <lsb_release>
4689 0.04s 0.01s 0K 0K - - NE 0 E 1% <apt-cache>
4684 0.04s 0.00s 132K 132K 0K 0K -- - R 0% atop
4673 0.02s 0.00s 0K 0K 0K 0K -- - S 0% sshd
4152 0.01s 0.00s 0K 0K 0K 0K -- - S 0% vmware-guestd
2302 0.00s 0.00s 0K 0K 0K 4K -- - S 0% kjournald
4688 0.00s 0.00s 0K 0K - - NE 0 E 0% <sh>
4686 0.00s 0.00s 0K 0K - - NE 0 E 0% <sh>
Se eu entendi isso correto há um não 'zumbis', mas eles ainda ocupam a maior parte do tempo cpu (que salta de 199% para 200%). Esse comportamento é esperado?
Além do iostat , você também deve considerar em cima ( link ) para identificar gargalos não-cpu.
O problema pode ser E / S de disco lento. Tente executar:
$ iostat -d -x 5 3
Há uma explicação da saída aqui
Os comandos do sistema de arquivos, como cp , não devem ocupar muito tempo ou memória da CPU, que é o que mostra top . Experimente o programa iotop (talvez seja necessário instalá-lo).
Como você está se conectando a uma máquina virtual, a lentidão pode ser de outras VMs no host físico. De dentro da sua máquina virtual, você não pode, geralmente, dizer quanta CPU você realmente tem, nem pode ver estatísticas sobre as taxas reais de I / O. Você precisa executar 'top' ou 'atop' no host físico.
Não consigo encontrar a fonte agora e peço desculpas, mas lembro que a leitura pode estar relacionada ao local onde a unidade virtual está armazenada. Se for armazenado e acessado através do NFS, então há uma enorme quantidade de sobrecarga e surra.
O Virtualbox tem opções para ajustar o cache de IO que você pode precisar examinar. Isso afeta programas simples que copiam dados como o cp.