processes not getting fair share of available disk I/O

[Kris Kennaway]

On Thu, Dec 14, 2006 at 02:37:31PM +0000, Dieter wrote:
> > Sorry, yes.  Nothing else contended for it though, so it doesn't
> > appear to be a source of performance problems - it is probably a
> > secondary effect from something else.  I guess you're running some old
> > version of FreeBSD since those line numbers don't correspond to
> > anything reasonable in the current 6.x source, so I dunno what
> > exactly.
> 
> FreeBSD 6.0

Erk.  How about retrying with something modern ;-)  We do fix lots of
bugs over time you know!

> > > > The rest looks fine at a quick glance too.
> > >=20
> > > What should I be looking for?  Do I need to collect stats for a long
> > > period of time, or is a few seconds enough?  Dd can kill the transfer
> > > in about 3 seconds.
> > 
> > You need to make sure your sampling while the system is in the bad
> > state.
> > 
> > A mutex that has a lot of acquisitions and a lot of contention for
> > those acquisitions is a performance bottleneck.  Nothing below falls
> > into that class - in particular it's definitely not Giant causing
> > performance loss to the filesystem.
> 
> Aren't the numbers (other than max and avg) going to depend a lot on how
> long I collect data?  Are you looking for one or two locks that have
> contention a couple orders of magnitude higher than everything else?

Yes, and with a large number of acquisitions.  i.e. it's not usually
an issue if a mutex is contended but is only acquired a few thousand
times out of billions of mutex operations, but it is an issue if it's
heavily used and also heavily contended.

> > Still looks like it's a driver and/or hardware problem, but you'd need
> > specialized knowledge to proceed with debugging it.
> 
> Maybe I didn't beat on it hard enough.  Data below is with two processes
> reading data from Ethernet and writing to disk.  (common Ethernet, different
> disks) and a loop with 3 copies of dd writing from /dev/zero to disks,
> and then 3 copies of dd reading the files back and writing to /dev/null.
> This ground away for a few minutes.

Interrupt CPU usage might be high, but the first thing you should do
is retry with 6.2-rc1 and work from there.

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/20061214/cb0266e6/attachment-0001.pgp