If you're only interested in the number of "read" or "write" calls to block devices this is Red Hat's SOP for determining that.
Using the block dump feature and a bit of scripting a high level
overview about the I/O actions processes are producing can be
gathered. To do so, complete the following:
Disable system logging for a short period of time (so it doesn't get
in the way of the data capture):
# service syslog stop # echo 1 > /proc/sys/vm/block_dump
Wait for the high iowait issue to occur, once it has past re-enable
syslog (or rsyslog if using that), and disable the block dump:
# service syslog start # echo 0 > /proc/sys/vm/block_dump
Using the following command parse the dmesg output for
READ/WRITE/dirtied actions being issued by certain processes:
# dmesg | awk '/(READ|WRITE|dirtied)/ {activity[$1]++} END {for (x in
activity) print x, activity[x]}'| sort -nr -k 2,2| head -n 10
kjournald(1425): 5984
kjournald(3681): 1269
pdflush(27301): 725
iostat(2913): 134
crond(26919): 61
crond(28985): 60
crond(7026): 54
sshd(28175): 50
sshd(15388): 50
nautilus(24498): 46
The example output above shows the top 10 processes that issued READ,
WRITE and dirtied operations during the time the block dump was
running. Using this data a high level overview of the number of
operations processes are issuing can be gathered and it can help
determine if a single process is contributing highly to iowait.
There are also several command line tools like atop and iotop that give you per-process iowait statistics and can be ran as part of a script (meaning they have batch modes that can do a single iteration for particular PIDs).
EDIT:
Doing more research it looks like you can get per-process iowait from /proc/$pid/stat (search for "Aggregated block I/O delays")