From owner-freebsd-amd64@FreeBSD.ORG Tue Jun 15 01:34:52 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E0B4316A4CF for ; Tue, 15 Jun 2004 01:34:52 +0000 (GMT) Received: from ojoink.com (center.ojoink.com [216.65.123.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCBED43D45 for ; Tue, 15 Jun 2004 01:34:52 +0000 (GMT) (envelope-from amd64list@jpgsworld.com) Received: (qmail 553 invoked by uid 89); 15 Jun 2004 01:34:16 -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:34:16 -0000 Message-Id: <5.2.0.9.2.20040614175419.0162dd00@127.0.0.1> X-Sender: amd64list@jpgsworld.com@mail.ojoink.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 14 Jun 2004 18:34:28 -0700 To: freebsd-amd64@freebsd.org From: JG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: recent -CURRENT changes were very bad for MySQL... X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2004 01:34:53 -0000 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.