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