pidstat -d 2
pidstat -d | sort -nk 3
iotop -d 2
好用啊...
2.
Use top and look for processes in the 'D' state, or ps aux | grep " D "
stat 中的參數意義如下:
D 不可中斷 Uninterruptable(usually IO)
R 正在運行,或在隊列中的進程
S 處於休眠狀態
T 停止或被追踪
Z 殭屍進程
W 進入內存交換(從內核2.6開始無效)
X 死掉的進程
3.
top - 09:34:12 up 2 days, 20:57, 2 users, load average: 1.83, 1.99, 2.03
Tasks: 59 total, 2 running, 57 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.3%us, 0.0%sy, 0.0%ni, 0.0%id, 99.7%wa, 0.0%hi, 0.0%si, 0.0%st
That 99.7% wa is iowait, it means the server is waiting for a process to complete an IO operation or in plain English, there is a delay in reading and/or writing data to the hard drive.
Here are some ways to get an idea of what is going on (in RPM based Distros this package is called "sysstat") and contains the very helpful binary called "iostat". There's another package I like called "dstat" that does a great job too.
Run
iostat -d 5
(it refreshes the data every 5 seconds):Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda1 2.07 5.27 28.66 1309570 7120384
sda2 0.00 0.03 0.04 7496 8832
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda1 27.15 0.00 357.68 0 1792
sda2 0.00 0.00 0.00 0 0
What we're seeing is that the iowait must be caused primarily by blocks being written to /dev/sda1 which is mounted as / (my root filesystem). So now we know the main cause is by an application constantly writing to the root partition, but we still don't know what process is directly responsible for this.
If you have a newer kernel it's often possible to view processes by io usage, you can test for this by running:
cat /proc/self/io
If the file is not found then you don't have io stats enabled in your kernel. Then you can check a suspected process by running
cat /proc/13/io (replace the 13 with the PID you want to check).
read_bytes: 0
write_bytes: 0
cancelled_write_bytes: 0
沒有留言:
張貼留言