On 04/06/2012 04:54 AM, Bluejay Adametz wrote:
3. The fact that the tar extraction process is so slow as to be effectively
useless, suggest
something of a larger problem.
I would expect tar to be more I/O bound.
If you submit multiple CPU-intensive tasks then you should see multiple
cores
go to high percent used. But if your tasks are I/O bound then the CPU %
will
not hit 100% as the process block for I/O.
hmmm.... perhaps the CPU and CPU scheduling are not the issues.
Can you try some other I/O bound processes, say, backups or just dd
if=/dev/sdwhatever of=/dev/null and see what happens?
How's memory look?
You're distributing jobs across a networked cluster, correct? In that
case network based I/O should be the bottleneck, especially if you're
untarring something that lives on an NFS share to another NFS share --
and this would become a serious problem (like 20min to untar something
tiny) if you've got an addressing collision somewhere in the network or
a device is connected via a slow physical connection.
The other day we had a major slowdown on one segment of a network, and
what caught the users' attention was "how slow OpenOffice is today".
OpenOffice wasn't being slow, but grabbing stuff from the NFS shares
sure was. It was simply because of a misconfigured Windows laptop
someone put on the network that was issuing erroneous responses to DHCP
requests -- which hadn't been an issue until a collision occured.
In a clustered environment I can only imagine you'd be incredibly more
sensitive to issues like this (and anything else network related).
-z
