Date: Thu, 14 Dec 2006 17:52:23 -0500 From: Kris Kennaway <kris@obsecurity.org> To: Dieter <freebsd@sopwith.solgatos.com> Cc: freebsd-questions@freebsd.org Subject: Re: processes not getting fair share of available disk I/O Message-ID: <20061214225223.GA99321@xor.obsecurity.org> In-Reply-To: <200612142237.WAA00195@sopwith.solgatos.com> References: <20061214182517.GA94080@xor.obsecurity.org> <200612142237.WAA00195@sopwith.solgatos.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. >=20 > 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. > > >=3D20 > > > 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. > >=20 > > You need to make sure your sampling while the system is in the bad > > state. > >=20 > > 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. >=20 > 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. >=20 > 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, differ= ent > 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 --Dxnq1zWXvFF0Q93v Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFgdWnWry0BWjoQKURAvDnAJ4+57TgQH1fy+TNMC8R6j6b6r8LxQCgmTDm OE0Td7wKgm2I7tyk6414uxs= =Rtjc -----END PGP SIGNATURE----- --Dxnq1zWXvFF0Q93v--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061214225223.GA99321>