From owner-freebsd-threads@FreeBSD.ORG Tue Jun 15 01:37:08 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F023316A4CE for ; Tue, 15 Jun 2004 01:37:07 +0000 (GMT) Received: from ojoink.com (center.ojoink.com [216.65.123.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id E31D443D48 for ; Tue, 15 Jun 2004 01:37:07 +0000 (GMT) (envelope-from amd64list@jpgsworld.com) Received: (qmail 658 invoked by uid 89); 15 Jun 2004 01:36:31 -0000 Received: from unknown (HELO MAINBX.jpgsworld.com) (amd64list@jpgsworld.com@24.10.96.33) by center.ojoink.com with SMTP; 15 Jun 2004 01:36:31 -0000 Message-Id: <5.2.0.9.2.20040614183523.015cdaa0@mail.ojoink.com> X-Sender: amd64list@jpgsworld.com@mail.ojoink.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 14 Jun 2004 18:36:45 -0700 To: freebsd-threads@freebsd.org From: JG In-Reply-To: References: <40CE0C9B.1080305@he.iki.fi> <01c301c45239$940781f0$6401a8c0@animal> <40CE0C9B.1080305@he.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: Possible Threading problem with -CURRENT / MySQL? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2004 01:37:08 -0000 I just posted this to -AMD64 and someone brought this discussion to my attention... anyway I'll repost it here since it seems to be a more relevant discussion: I got a couple emails from people telling me I should retest because some changes have been committed recently that might effect my MySQL benchmarks. Well I just did a buildworld and kernel to -CURRENT & it did effect the results alright... just not the way we wanted them to: amd64f# super-smack update-select.smack 30 10000 Query Barrel Report for client smacker connect: max=46ms min=2ms avg= 26ms from 30 clients Query_type num_queries max_time min_time q_per_s select_index 300000 2 0 958.05 update_index 300000 2 0 958.05 In all my previous tests I think that number was at least 2000/qps (and that was bad) and as much as 4000/qps. Whatever was changed recently really killed performance in this area. This is a SMP kerenel using SCHED_ULE. .. debugging is turned off in kernel of course. Whatever was changed is producing very erratic benchmark results from bad to worse.... here is an example: (keep in mind this box is for testing only, nothing else is going on on this box) I ran some short tests below (notice 100 below vs 10000 above) amd64f# super-smack update-select.smack 30 100 Query Barrel Report for client smacker connect: max=24ms min=2ms avg= 10ms from 30 clients Query_type num_queries max_time min_time q_per_s select_index 3000 1119 0 60.64 update_index 3000 2185 0 60.64 amd64f# super-smack update-select.smack 30 100 Query Barrel Report for client smacker connect: max=292ms min=1ms avg= 54ms from 30 clients Query_type num_queries max_time min_time q_per_s select_index 3000 4 0 3167.06 update_index 3000 1 0 3167.06 amd64f# super-smack update-select.smack 30 100 Query Barrel Report for client smacker connect: max=26ms min=3ms avg= 10ms from 30 clients Query_type num_queries max_time min_time q_per_s select_index 3000 1891 0 32.73 update_index 3000 1891 0 32.73 amd64f# amd64f# super-smack update-select.smack 30 100 Query Barrel Report for client smacker connect: max=37ms min=3ms avg= 10ms from 30 clients Query_type num_queries max_time min_time q_per_s select_index 3000 10 0 757.05 update_index 3000 11 0 757.05 amd64f# super-smack update-select.smack 30 100 Query Barrel Report for client smacker connect: max=39ms min=5ms avg= 15ms from 30 clients Query_type num_queries max_time min_time q_per_s select_index 3000 11 0 2988.89 update_index 3000 2 0 2988.89 Those were ran one after the other with nothing changed in between. Just thought I would give you guys a heads up.