I have a 24 core machine with 94.6GiB RAM running Ubuntu server 10.04. The box is experiencing high %iowait, unlike another server we have (4 cores) running the same types and amounts of processes. Both machines are connected to a VNX Raid fileserver, the 24-core machine via 4 FC cards, and the other via 2 gigabit ethernet cards. The 4-core machine currently outperforms the 24-core machine, has higher CPU usage and lower %iowait.
In 9 days uptime, %iowait averages at 16%, and is routinely above 30%. Most of the time CPU usage is very low, around 5% (due to the high iowait). There is ample free memory.
One thing I don't understand is why all the data appears to be going through device sdc rather than going through the data movers directly:
avg-cpu: %user %nice %system %iowait %steal %idle 6.11 0.39 0.75 16.01 0.00 76.74 Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn sda 0.00 0.00 0.00 1232 0 sdb 0.00 0.00 0.00 2960 0 sdc 1.53 43.71 44.54 36726612 37425026 dm-0 0.43 27.69 0.32 23269498 268696 dm-1 1.00 1.86 7.74 1566234 6500432 dm-2 0.96 1.72 5.97 1442482 5014376 dm-3 0.49 9.57 0.18 8040490 153272 dm-4 0.00 0.00 0.00 1794 24 dm-5 0.00 0.00 0.00 296 0
Another piece of the puzzle is that tasks frequently go into uninteruptable sleep mode (in top), also probably due to the io holdup.
What can I look at to help diagnose the problem? Why is all the data going through /dev/sdc? Is that normal?
The network connection and VNX read/write capacity have been ruled out as bottlenecks. We can reach speeds of 800MB/s with the 4 bonded NICs (round-robin). The fiber channel cards are not yet being used. The VNX is well able to handle the IO (RAID6, 30x2TB 7.2kRPM disks per pool in two pools (60 disks total), about 60% read).
Ignore above about dm and sdc, they are all internal disks, and not part of the problem.
We think the issue might be with the nfs mounts or TCP (we have 5 mounts to 5 partitions on the VNX), but don't know what exactly. Any advice?
dmstands for device mapper, not data mover. This question would probably do much better at Server Fault.