Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 21 Jun 2005 14:15:42 +0200
From:      Michael Schuh <michael.schuh@gmail.com>
To:        Mark Kirkwood <markir@paradise.net.nz>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: FreeBSD MySQL still WAY slower than Linux
Message-ID:  <1dbad315050621051525f4c6fc@mail.gmail.com>
In-Reply-To: <42B74DF9.9020706@paradise.net.nz>
References:  <1dbad315050620034565892ee@mail.gmail.com> <42B6A528.2000204@paradise.net.nz> <1dbad315050620044862e8a7f6@mail.gmail.com> <42B74DF9.9020706@paradise.net.nz>

next in thread | previous in thread | raw e-mail | index | archive | help
hello,

first sorry for my bad english, with <noop> i mean no operation.

i can live with a better performance from postgresql under RELENG_5 :-D
i find it great.

As i sayed i have the installations always made in the same way, so that i =
mean.
I mean i have alwas made the swap on the first gig of the disk, and
the installation
on the rest of the disk. and i have no multiple os'es on these disk.

I know that other diskpart's have other performance...... :-D

i mean i have really strictly regarded where my os'es are installed
for these tests.

what i not can ensure, is that the Gentoo uses the same parts for the
programs, relying
of the implemantation from ext2fs/ext3fs than BSD under UFS.

But i think really that are enough reasons to say this test speaking a
real language,
and gave me not bad results.

I be not a noob or an newby, so that i know that the io performance of a di=
sk is
related to the sectors that i use for regarding this performance. :-D

i have made the test always on the <same> hardware, not compatible or equal=
,
really the same, same disk, same processor, same board, same ram, same
ethernet-card,
all same........

i would not say look for a faster io-performance, that is not the only
factor for database performance, but what is when your disk-access=20
uses the double of time as before?

then can you not say "ohhh my problem is not related to disk-io" ;-)

i would not say that the io of disk ist the only important factor, but
it is in fact an
important factor.

make a simple test: install a database-intensive application on an PII400
with DDRS-4,3GB SCSI-disk and make 500.000 inserts in an postgresql and an =
mysql
database. so you can see that it uses many many time, change the disk to an=
=20
ATA66 disk with good performance (better then the DDRS or DCAS) and
then you see,
that the disk-prformance is an important fact.

i would you only make sensible for the view that you cannot only digging at=
 the
ipc-performance or the threading. I know that are also important factors,
but what is if the base of all of these factors are lame?

then you are lying on an mixed error behaviour that are not really
representative.
you search the error in first time on the wrong place.

i think first view the diskperformance in versus of the Os'es and the
versions, then
digging deeper and search the oil in threading.....:-))

i woul not start a principle discussion, that is not my target, my
target is an really performant OS, that go's he's way forward and not
backward's.

I have seen that the disk-performance (ata-related) is much slower in
RELENG_5 than in
RELENG_4, and this is a step backwards to me, if its so much slower.

about five or ten percent is not really bad an can comes from an other
scheduling, as you can see in dragonfly, but halv as good as before
ist for me not acceptable for
production uses.

best regards

michael

2005/6/21, Mark Kirkwood <markir@paradise.net.nz>:
> Michael Schuh wrote:
> > Hello,
> >
> > yes random IO is more targetted to Databases.
> > noop, i have the installation always made in the same way, and i have r=
espected
> > the different diskperformace in different disk-parts.....
> > this was the reason for
> >
> > #cd /;
> >
> > at the beginning of my tests.
> > In the first test i have me shooting self in my foot and i bites me in
> > my ass :-)))
> >
>=20
> I was referring to the partitions and slices on the physical disk - each
> operating system is installed in a different one of these, and so is in
> a different physical part of the disk - hence you cannot reliably
> compare IO rates between them (This very issue has been discussed before
> I recall - try a Google search, as it is quite interesting).
>=20
> > my suggestion going more in the direction...first solve all disk(ata) r=
elated
> > performace issues, then test the mysql-performaces issues again to secu=
re
> > that you are not lying on an mixing of many problems.... :-)
> >
>=20
> While noone would complain about faster sequential IO, it is almost
> certainly not the issue effecting database performance - for instance I
> find Postgresql consistently faster on RELENG_5 (5.3 onwards) than on
> RELENG_4 (using the pgbench program).
>=20
> cheers
>=20
> Mark
>=20
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1dbad315050621051525f4c6fc>