From owner-freebsd-performance@FreeBSD.ORG Mon Jun 20 14:51:14 2005 Return-Path: X-Original-To: performance@FreeBSD.org Delivered-To: freebsd-performance@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E643C16A41C for ; Mon, 20 Jun 2005 14:51:13 +0000 (GMT) (envelope-from dsze@distrust.net) Received: from mail.distrust.net (mail.distrust.net [69.93.230.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3FBB43D1D for ; Mon, 20 Jun 2005 14:51:13 +0000 (GMT) (envelope-from dsze@distrust.net) Received: from eeyore.distrust.net (CPE00a0c978120d-CM00122570472e.cpe.net.cable.rogers.com [70.28.248.121]) (authenticated bits=0) by mail.distrust.net (8.13.3/8.13.3) with ESMTP id j5KEpCUs021026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 20 Jun 2005 09:51:13 -0500 (CDT) (envelope-from dsze@distrust.net) Message-Id: <6.2.1.2.2.20050620105116.06376688@wheresmymailserver.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 20 Jun 2005 10:51:30 -0400 To: performance@FreeBSD.org From: David Sze Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV 0.85.1/946/Sun Jun 19 03:41:16 2005 on mail.distrust.net X-Virus-Status: Clean Cc: Subject: Re: FreeBSD MySQL still WAY slower than Linux X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2005 14:51:14 -0000 At 04:59 PM 19/06/2005 +0100, Robert Watson wrote this to All: >BTW, could you run 'file' on the Linux and FreeBSD MySQL binaries and >confirm that they're both either 32-bit i386 binaries, or 64-bit amd64 >binaries? I can no longer run tests on the machine because it's in production, but I will be re-running the tests on a different machine in the next few days, for reasons outlined below. They should both be amd64 binaries, I compiled from ports for FreeBSD and installs the x86_64 RPM for CentOS. >BTW, could you confirm that on 6.x, you're setting /etc/malloc.conf so >that it's not scrubbing memory on free()? In particular: > > ln -s jz /etc/malloc.conf > >as root. Most 6.x debugging features are set as part of the kernel >configuration, and your performance results suggest that you've caught >them all already, I think, but this one is user space. Also, make sure >you are compiling without INVARIANT_SUPPORT -- for packet send tests, I >find that even without INVARIANTS, I see a 4% hit for having >INVARIANT_SUPPORT in the kernel. I was using "ln -s aj /etc/malloc.conf" because I read somewhere that AJ were the only debugging options enabled in -CURRENT. I'll use "ajz" for the next set of tests. I had everything in the "Debugging for use in -current" section in GENERIC "nooptions"ed in my kernel config file, so INVARIANT_SUPPORT was gone. The reason I'm re-running the tests is due to things pointed out by various people last week. In particular: - ufs+soft_updates and ext3 are both async, but they guarantee consistency. So mounting the ext3 partition as sync and comparing it to ufs+soft_updates was meaningless. - Consistency guarantees are useless for databases because they have pretty much zero filesystem meta data updates. - MyISAM has no data durability guarantees, so using it on an async file system like ufs+soft_updates or ext3 is also meaningless (at least for my application, where writes are more common than reads, and durability is important). You can get durability with MyISAM by mounting sync, but write performance is horrible. - InnoDB has durability guarantees on an async filesystem (it uses one of fdatasync/fsync/O_SYNC/etc. at the appropriate times), so the results of the update-select super-smack benchmark look a lot different. I'll be re-running super-smack against an InnoDB table. Any additional requests for configurations to test, or other tweaking suggestions? This is what I'll be trying: FreeBSD/amd64 4.11-RELEASE, linuxthreads FreeBSD/amd64 5.4-RELEASE, libpthread FreeBSD/amd64 5.4-RELEASE, libpthread, process scope FreeBSD/amd64 6.0-CURRENT, libpthread FreeBSD/amd64 6.0-CURRENT, libpthread, process scope FreeBSD/amd64 6.0-CURRENT, libthr, system scope FreeBSD/amd64 6.0-CURRENT, libthr, process scope CentOS/amd64 4.0 The different threading libraries are more for completeness. In my last test I saw <10% difference between them on amd64.