From owner-freebsd-current@FreeBSD.ORG Fri Oct 22 06:01:43 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 A7F5516A4CE for ; Fri, 22 Oct 2004 06:01:43 +0000 (GMT) Received: from gundel.de.clara.net (gundel.de.clara.net [212.82.225.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6996743D31 for ; Fri, 22 Oct 2004 06:01:43 +0000 (GMT) (envelope-from jesk@killall.org) Received: from port-212-202-52-250.dynamic.qsc.de ([212.202.52.250] helo=turbofresse) by gundel.de.clara.net with smtp (Exim 4.30; FreeBSD) id 1CKseY-000ORa-N7 for freebsd-current@freebsd.org; Fri, 22 Oct 2004 08:11:54 +0200 Message-ID: <001301c4b7fc$99487240$45fea8c0@turbofresse> From: "jesk" To: Date: Fri, 22 Oct 2004 08:01:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: FreeBSD5.3-RC1 MySQL Performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list 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 06:01:43 -0000 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´s, 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 files. the MySQL backend was MyISAM. with both setups the mysql was always under high load which seemed to me for a good sign to recognize expressive values on thread execution and mysql performance without loosing to much time in i/o. the benchmark is executing 1000 sql-select queries*10 concurrent clients 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 ---- same test (same parameters) but with a update query first and then a select query on the same key i realized worse values for freebsd: ---- 2027.52 queries per second (pthreads without process scope threads, sched_4bsd and preemption) 1146.66 queries per second (pthreads with process scope threads, sched_4bsd and preemption) 3040.78 queries per second (linuxthreads, sched_4bsd and preemption) fedora result: 3920.21 queries per second ---- i checked if i could tune up the update query procedure with writing on a ramdisk, but this wasnt a highly profit. if i could use the mixture of linuxthreads on updates and pthreads on select queries without the use of proc scope it would be a good answer to linux, but fedora wasnt reachable in its update operation.. here the relevant used mysql values in this test: ---- query_cache_size=64000000 key_buffer_size=1024M table_cache=128 thread_cache_size=128 max_connections=1000 ---- maybe someone got some hints for improvement of this situation... regards, jesk