From owner-freebsd-stable@FreeBSD.ORG Tue Jun 21 12:15:44 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BF4D16A41C for ; Tue, 21 Jun 2005 12:15:44 +0000 (GMT) (envelope-from michael.schuh@gmail.com) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA3A343D5D for ; Tue, 21 Jun 2005 12:15:43 +0000 (GMT) (envelope-from michael.schuh@gmail.com) Received: by nproxy.gmail.com with SMTP id g2so65619nfe for ; Tue, 21 Jun 2005 05:15:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bZzsX/ZpE4wR9WkQNbi6Awgnwpinv4Xo15tJz/1x/+ihjiP3po4FkEzxzcMsOR4w8qmHYy8J8Uynvpbio92djuUXkQT5v+2NjPJNz3JedjBhmmmsCmCay21Etnm68VJ9yVT4FwmoCho5jXSgo66q8jKcqH6esGZlSG2sdyACZck= Received: by 10.48.43.18 with SMTP id q18mr107512nfq; Tue, 21 Jun 2005 05:15:42 -0700 (PDT) Received: by 10.48.244.20 with HTTP; Tue, 21 Jun 2005 05:15:42 -0700 (PDT) Message-ID: <1dbad315050621051525f4c6fc@mail.gmail.com> Date: Tue, 21 Jun 2005 14:15:42 +0200 From: Michael Schuh To: Mark Kirkwood In-Reply-To: <42B74DF9.9020706@paradise.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1dbad315050620034565892ee@mail.gmail.com> <42B6A528.2000204@paradise.net.nz> <1dbad315050620044862e8a7f6@mail.gmail.com> <42B74DF9.9020706@paradise.net.nz> Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD MySQL still WAY slower than Linux X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Michael Schuh List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2005 12:15:44 -0000 hello, first sorry for my bad english, with 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 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 : > 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 >