Date: Tue, 28 Jun 2005 18:29:59 +0200 From: Michael Schuh <michael.schuh@gmail.com> To: Paul Mather <paul@gromit.dlib.vt.edu> Cc: freebsd-stable@freebsd.org, Roman Neuhauser <neuhauser@sigpipe.cz> Subject: Re: FreeBSD MySQL still WAY slower than Linux Message-ID: <1dbad31505062809292af0d294@mail.gmail.com> In-Reply-To: <1119973124.7900.20.camel@zappa.Chelsea-Ct.Org> References: <1dbad315050621051525f4c6fc@mail.gmail.com> <200506211451.j5LEpA2W024350@lurza.secnetix.de> <20050628092126.GB48140@isis.sigpipe.cz> <1119973124.7900.20.camel@zappa.Chelsea-Ct.Org>
next in thread | previous in thread | raw e-mail | index | archive | help
Yes, i know that and i agree with them. that was the reason, why my disk is tiled on first physical Gigabyte for Sw= ap, 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@gromit.dlib.vt.edu>: > On Tue, 2005-06-28 at 11:21 +0200, Roman Neuhauser wrote: > > # olli@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. >=20 > The point people are making is that location can have a significant > effect on performance, and so should not be dismissed out of hand. >=20 > 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): >=20 > 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. >=20 > Seek times: > Full stroke: 250 iter in 5.159189 sec =3D 20.637 msec > Half stroke: 250 iter in 4.206125 sec =3D 16.825 msec > Quarter stroke: 500 iter in 7.151951 sec =3D 14.304 msec > Short forward: 400 iter in 2.794380 sec =3D 6.986 msec > Short backward: 400 iter in 4.135579 sec =3D 10.339 msec > Seq outer: 2048 iter in 0.332711 sec =3D 0.162 msec > Seq inner: 2048 iter in 0.363152 sec =3D 0.177 msec > Transfer rates: > outside: 102400 kbytes in 7.677977 sec =3D 13337 kbyte= s/sec > middle: 102400 kbytes in 9.151475 sec =3D 11189 kbyte= s/sec > inside: 102400 kbytes in 14.345492 sec =3D 7138 kbyte= s/sec >=20 > 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? >=20 > Cheers, >=20 > Paul. > -- > e-mail: paul@gromit.dlib.vt.edu >=20 > "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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1dbad31505062809292af0d294>