From owner-freebsd-stable@FreeBSD.ORG Tue Jun 21 15:01:52 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 1997216A41C for ; Tue, 21 Jun 2005 15:01:52 +0000 (GMT) (envelope-from michael.schuh@gmail.com) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 992A143D49 for ; Tue, 21 Jun 2005 15:01:51 +0000 (GMT) (envelope-from michael.schuh@gmail.com) Received: by nproxy.gmail.com with SMTP id g2so72024nfe for ; Tue, 21 Jun 2005 08:01:50 -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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=CWhEiDjVW7nvJiLuxk4l4FwmnKX4oX4z/obAsONiH/01SIDWl3sFUkvH10usPbf4un0MEl9IIaH9bim9kymbrrEc9g/iTqlgDpW4hn7XNTD/O3RiYkjjvbqlDEMRzZv5UsBiqHL5aHYl5iZzH+rlirWSqNCwajC/jCXv4a+aLUg= Received: by 10.48.144.8 with SMTP id r8mr111979nfd; Tue, 21 Jun 2005 08:01:50 -0700 (PDT) Received: by 10.48.244.20 with HTTP; Tue, 21 Jun 2005 08:01:49 -0700 (PDT) Message-ID: <1dbad31505062108011b812ba8@mail.gmail.com> Date: Tue, 21 Jun 2005 17:01:49 +0200 From: Michael Schuh To: freebsd-stable@freebsd.org, Michael Schuh In-Reply-To: <200506211451.j5LEpA2W024350@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1dbad315050621051525f4c6fc@mail.gmail.com> <200506211451.j5LEpA2W024350@lurza.secnetix.de> Cc: 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 15:01:52 -0000 Hello Oliver, ahhhhh, that are the hint that i missed. now i have another question, if i use the same Os in 2 versions (RELENG_4, RELENG_5) can i hope that the tests are made on the same part of disk? or in other words can an dd on the two OS' es so much different because they use an totally other part of disk? I think no, the strategie from dd under one OS should not be changed if the OS-Version has changed. the part with serial IO related to database-performance have i understand, but i quests me have the others understand my meanings? best regards Michael Schuh 2005/6/21, Oliver Fromme : > Michael Schuh wrote: > > As i sayed i have the installations always made in the same way, so th= at 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. >=20 > The problem is that the file (from "dd of=3Dfoo") can still > end up at completely different physical places on the disk. >=20 > It depends on the filesystem (ext2, ext3, UFS, whatever) > and on the allocation strategies of the filesystem code. > UFS might start filling cylinder groups from the beginning > of the disk, while ext3 might start at the end (does ext3 > even _have_ cylinder groups?). This was just an example, > but you get the idea. >=20 > Of course, it also depends on how much data there already > is on the filesystem, and how it is distributed over the > disk. >=20 > For accurate measurements and comparisons, you have to make > sure to use _exactly_ the same physical location on the > disk. From userland you don't have a way to control the > physical allocation of files. Therefore, the only reliable > way is to leave an unused partition on the disk, do _not_ > put a filesystem on it, and use the raw device in the =BBdd=AB > command. If you do this, you will always hit the same > physical location on the disk. >=20 > But then again -- as others have already mentioned, serial > write speed is not the most important factor for database > performance (although the WAL journal files of advanced > transactional databases like PostgreSQL are written in a > sequential way), so the usefulness of this "benchmark" is > very debatable. >=20 > Best regards > Oliver >=20 > -- > Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 M=FCnchen > Any opinions expressed in this message may be personal to the author > and may not necessarily reflect the opinions of secnetix in any way. >=20 > "I started using PostgreSQL around a month ago, and the feeling is > similar to the switch from Linux to FreeBSD in '96 -- 'wow!'." > -- Oddbjorn Steffensen >