[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: Possible evidence of performance regression for 8.1-S (vs. 7.1) David Wolfskill Wed Oct 27 04:00:45 2010

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:
> > 
> >      start        stop    real   user    sys  os
> > 1288111167  1288111298  131.14  12.77  17.88  7.1-R+
> > 1288109542  1288109653  111.26  12.03  14.88  8.1-S [7.1-R+ userland]
> > 1288112673  1288112768   94.88   9.41  12.87  8.1-S
> 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:
> vfs.hirunningspace=8388608
> vfs.lorunningspace=6291456
> vfs.ufs.dirhash_maxmem=8388608
> vfs.read_max=32

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.

David H. Wolfskill                              [EMAIL PROTECTED]
Depriving a girl or boy of an opportunity for education is evil.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.