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