FreeBSD MySQL still WAY slower than Linux
Michael Schuh
michael.schuh at gmail.com
Tue Jun 28 16:30:03 GMT 2005
Yes, i know that and i agree with them.
that was the reason, why my disk is tiled on first physical Gigabyte for Swap,
and the rest for the system....
my target was to compare 2 Versions not 2 Os-Types like FreeBSD and Linux,
but FreeBSD and FreeBSD, in cases RELENG_4 with RELENG_5.
so that the little difference between the different places for files,
remember i install everytime at the beginning of second Gig on disk,
should be flawlessy and not make the results so big, that the RELENG_4
has the double of speed from RELENG_5!
best regards
michael
2005/6/28, Paul Mather <paul at gromit.dlib.vt.edu>:
> On Tue, 2005-06-28 at 11:21 +0200, Roman Neuhauser wrote:
> > # olli at lurza.secnetix.de / 2005-06-21 16:51:10 +0200:
> > > For accurate measurements and comparisons, you have to make
> > > sure to use _exactly_ the same physical location on the
> > > disk.
> >
> > No you don't. You want to make a side-by-side comparison
> > of two products, and if one of them underperforms, it just
> > underperforms. You cannot use a poor location selection
> > strategy in the driver as an excuse for poor operation.
>
> The point people are making is that location can have a significant
> effect on performance, and so should not be dismissed out of hand.
>
> Here is what I get when I run diskinfo on one of the (somewhat elderly)
> disks I use in my desktop system (this is a drive I use for data, and it
> is idle):
>
> zappa# diskinfo -tv /dev/ad4
> /dev/ad4
> 512 # sectorsize
> 25590620160 # mediasize in bytes (24G)
> 49981680 # mediasize in sectors
> 49585 # Cylinders according to firmware.
> 16 # Heads according to firmware.
> 63 # Sectors according to firmware.
>
> Seek times:
> Full stroke: 250 iter in 5.159189 sec = 20.637 msec
> Half stroke: 250 iter in 4.206125 sec = 16.825 msec
> Quarter stroke: 500 iter in 7.151951 sec = 14.304 msec
> Short forward: 400 iter in 2.794380 sec = 6.986 msec
> Short backward: 400 iter in 4.135579 sec = 10.339 msec
> Seq outer: 2048 iter in 0.332711 sec = 0.162 msec
> Seq inner: 2048 iter in 0.363152 sec = 0.177 msec
> Transfer rates:
> outside: 102400 kbytes in 7.677977 sec = 13337 kbytes/sec
> middle: 102400 kbytes in 9.151475 sec = 11189 kbytes/sec
> inside: 102400 kbytes in 14.345492 sec = 7138 kbytes/sec
>
> Note how the transfer rate for the "outside" is almost twice that of the
> "inside." Suppose I run tests on two different operating systems, one
> of which resides in a partition on the "inside" portion and the other in
> one on the "outside" portion. (Note that however good or bad it may be,
> the "location selection strategy in the driver" can only lay out data
> within the confines of the partition.) Now, I do a "dd" test and find
> that the "outside" OS is almost twice as fast as the other. Would it be
> wise to conclude that the slower OS is woefully inefficient compared to
> the faster one? Suppose both tests turn out to take roughly the same
> time. Should I conclude that the OS residing on the "inside" is just as
> efficient as the other OS?
>
> Cheers,
>
> Paul.
> --
> e-mail: paul at gromit.dlib.vt.edu
>
> "Without music to decorate it, time is just a bunch of boring production
> deadlines or dates by which bills must be paid."
> --- Frank Vincent Zappa
>
More information about the freebsd-stable
mailing list