From owner-freebsd-performance@FreeBSD.ORG Wed Oct 27 10:55:07 2010 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 126F9106564A for ; Wed, 27 Oct 2010 10:55:07 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id CF9198FC13 for ; Wed, 27 Oct 2010 10:55:06 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.4/8.14.4) with ESMTP id o9RAt6KE013433 for ; Wed, 27 Oct 2010 03:55:06 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.4/8.14.4/Submit) id o9RAt6Le013432 for freebsd-performance@freebsd.org; Wed, 27 Oct 2010 03:55:06 -0700 (PDT) (envelope-from david) Date: Wed, 27 Oct 2010 03:55:06 -0700 From: David Wolfskill To: freebsd-performance@freebsd.org Message-ID: <20101027105506.GD9443@albert.catwhisker.org> References: <20101021224237.GG52404@albert.catwhisker.org> <4CC6C396.1010905@freebsd.org> <20101026121352.GC2262@albert.catwhisker.org> <20101020174854.GZ21226@albert.catwhisker.org> <20101021215330.GA86224@dan.emsphone.com> <20101021224237.GG52404@albert.catwhisker.org> <4CC6C396.1010905@freebsd.org> <20101026174501.GH2262@albert.catwhisker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yudcn1FV7Hsu/q59" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Subject: Re: Possible evidence of performance regression for 8.1-S (vs. 7.1) X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 10:55:07 -0000 --yudcn1FV7Hsu/q59 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 27, 2010 at 11:54:07AM +0200, Ivan Voras wrote: > ... > > the 8.x reference machine, and each terminated with a status code of 0: > >=20 > > start stop real user sys os > > 1288111167 1288111298 131.14 12.77 17.88 7.1-R+ >=20 > > 1288109542 1288109653 111.26 12.03 14.88 8.1-S [7.1-R+ userland] >=20 > > 1288112673 1288112768 94.88 9.41 12.87 8.1-S >=20 > There's a slight problem here: 8.1 with 7.1 userland should, in this > test, behave the same as 8.1 with 8.1 userland. There have been no > breakthroughs in gzip decompression or compiler optimization between > those two releases that would make 8.1 userland faster. I'm reporting what I measured. That said, we do have some history of variations in network activity (outside of anything directly involving systems under test), so it's possible that since these tests were so brief, each occurred in its own idiosyncratic "network ecology", thus skewing the reported results. I could re-run the tests easily enough, and increase the number of iterations (perhaps by a factor of 5 or 10).... > The most probable cause for the difference is simply disk drive location > - inner vs outer tracks (you can run diskinfo -vt on the drive - it's > non-destructive). This may also be the cause for your originally noticed > speed difference. I was using the same (4-spindle RAID 0 group) destination file system on the same machine for every one of those tests. Against what might I compare? > You could try some IO tuning on the box with sysctls like: >=20 > vfs.hirunningspace=3D8388608 > vfs.lorunningspace=3D6291456 > vfs.ufs.dirhash_maxmem=3D8388608 > vfs.read_max=3D32 Hmmm.... I'll look into these. > ... but if the problem is due to the disk track locations, it's not > really a problem. Well, as noted, it was the same file system each time. Precisely which blocks were allocated is not, as far as I know, not somethiong over which I have much influence or any control. But going back to the original issue -- recall, the above was intended to test just the NFS component, which was expected to be somewhere between "small" and "negligible" with respect to the originally-reported apparent discrepancy -- I was seeing consistent results of a "precious workload" taking a little under 6 hours under 7.1-R+, and a bit over 7 hours under vanilla 8.1-S. That *is* a problem, as I cannot justify a migration to a branch of FreeBSD that imposes about a 23% penalty in elapsed time on this workload. I want folks at work to have more reason to want to use (newer branches of) FreeBSD, not less. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --yudcn1FV7Hsu/q59 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkzIBQkACgkQmprOCmdXAD130QCgh+rmcnCDKAkJYDH4SY2BgRoQ SKQAn36CbkOLGKh4G0lZwU3zeGycbY36 =2vL6 -----END PGP SIGNATURE----- --yudcn1FV7Hsu/q59--