From owner-freebsd-current@FreeBSD.ORG Fri Oct 22 17:18:17 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 10AA816A4CF; Fri, 22 Oct 2004 17:18:17 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A87043D4C; Fri, 22 Oct 2004 17:18:16 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) i9MHIEUT024546; Fri, 22 Oct 2004 13:18:14 -0400 (EDT) Date: Fri, 22 Oct 2004 13:18:14 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Scott Long In-Reply-To: <417938C0.9050902@freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: jesk cc: freebsd-current@freebsd.org Subject: Re: FreeBSD5.3-RC1 MySQL Performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2004 17:18:17 -0000 On Fri, 22 Oct 2004, Scott Long wrote: > jesk wrote: > > Hello, > > > > i found some time to make some performance tests with mysql under > > FreeBSD5.3-RC1. Hardware is a HP DL360 with 2x2,8GHz Xeon CPU=B4s, 2GB, > > deactivated HTT and u160/10krpm scsi drive. For reference values i took= a > > RedHat Fedora with native threads (NPTL) on 2.6 kernel and the same > > hardware. for benchmarks i used super-smack with the default smack file= s. > > the MySQL backend was MyISAM. > > > > with both setups the mysql was always under high load which seemed to m= e for > > a good sign to recognize expressive values on thread execution and mysq= l > > performance without loosing to much time in i/o. > > > > the benchmark is executing 1000 sql-select queries*10 concurrent client= s on > > a 90k row table with a random not really high cacheable where-statement= on > > the index: > > ---- > > 15985 queries per second > > (pthreads without process scope threads, sched_4bsd and preemption) > > 6139 queries per second > > (pthreads with process scope threads, sched_4bsd and preemption) > > 10779 queries per second > > (linuxthreads, sched_4bsd and preemption) > > fedora result: > > 11900 queries per second > > ---- > > Your results for system scope threads is actually pretty good and is > quite a bit higher than what I've gotten in my tests. Your process > scope thread is about the same that I've seen, and indeed indicates > a serious problem with KSE process scope threads. Hopefully the threads > folks can look at this soon. Your Fedora results are quite a bit lower > than what I got on RHEL3, but that's a very different comparison. > Overall, I'm very encouraged by this; your test methods look very good > and I'm happy that the system scope test did so well. David made a recent change that speeded up system scope threads. We're not sure why process scope threads don't do as well. What is interesting is that disk I/O such as the crew test program from Butenhof's tests, performs much better with process scope threads than with system scope threads (crew spawns a bunch of worker threads to recursively search a directory for files containing a certain character sequence). --=20 Dan Eischen