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
pgprbmivFmi6T.pgp
Description: PGP signature