processes not getting fair share of available disk I/O
kris at obsecurity.org
Thu Dec 14 15:34:44 PST 2006
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20061214/cb0266e6/attachment-0001.pgp
More information about the freebsd-questions