From owner-freebsd-stable@FreeBSD.ORG Tue Jun 28 09:21:28 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 59DD816A41C for ; Tue, 28 Jun 2005 09:21:28 +0000 (GMT) (envelope-from neuhauser@sigpipe.cz) Received: from isis.sigpipe.cz (fw.sigpipe.cz [62.245.70.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A8CB43D48 for ; Tue, 28 Jun 2005 09:21:27 +0000 (GMT) (envelope-from neuhauser@sigpipe.cz) Received: by isis.sigpipe.cz (Postfix, from userid 1001) id D898C1F87BEE; Tue, 28 Jun 2005 11:21:26 +0200 (CEST) Date: Tue, 28 Jun 2005 11:21:26 +0200 From: Roman Neuhauser To: freebsd-stable@FreeBSD.ORG, Michael Schuh Message-ID: <20050628092126.GB48140@isis.sigpipe.cz> References: <1dbad315050621051525f4c6fc@mail.gmail.com> <200506211451.j5LEpA2W024350@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200506211451.j5LEpA2W024350@lurza.secnetix.de> User-Agent: Mutt/1.5.9i Cc: Subject: Re: FreeBSD MySQL still WAY slower than Linux X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2005 09:21:28 -0000 # 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. In all honesty, I'm getting somewhat irritated by all the "dd is meaningless performance measurement tool, use something real" and similar arguments: dd is a real command for real work, and if it shows abysmal performance of sequential writes, then there's a problem. > 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. Well, how about a few GB large table physically ordered ("clustered") on a column, that goes through repeated sequential scans? This *is* a real-world situation, and every bit of speed counts (the live server I'm talking about has the database on SCSI disks, but development machines frequently differ). -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991