processes not getting fair share of available disk I/O (was: Re: TCP parameters and interpreting tcpdump output )

[Kris Kennaway]

On Tue, Nov 21, 2006 at 11:12:38PM +0000, Dieter wrote:
> > I'm surprised that you're seeing that much of a "hang".  Even if the disks
> > are busy, the system should slow down all disk processes equally, so no
> > one process "blocks", but they're all a little slower.
> 
> I collected a bit of data:
> 
> While copying a large file from disk1 to disk2,
> 
> time ls on a small directory on disk3 (not cached in memory)
> 
> real    0m0.032s
> user    0m0.000s
> sys     0m0.003s
> 
> time ls on a small directory on disk2
> 
> real    4m51.911s
> user    0m0.000s
> sys     0m0.002s
> 
> I expect access to a busy disk to take longer, but 5 minutes is
> a bit much.  And that's the root directory of the filesystem,
> it didn't have to follow a long chain of directories to get there.
> 
> Sometimes I see long delays when accessing disk3, but it is
> behaving at the moment.

ls still has to acquire a number of locks in order to be sure that the
contents of the directory aren't changing.  If there are lots of other
processes all competing for these locks, it will be slow.  It looks
like that's the case on your system, although details of your workload
have been trimmed from your email.

This should be better in a future version of FreeBSD (when it's safe
to use shared locks instead of exlusive for vfs lookups) but today
there may not be much you can do apart from lowering the load.

Kris

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20061122/e9b68592/attachment.pgp