From owner-freebsd-threads@FreeBSD.ORG Tue Jun 15 23:22:45 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 2DB5616A4CE for ; Tue, 15 Jun 2004 23:22:45 +0000 (GMT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id E80DD43D31 for ; Tue, 15 Jun 2004 23:22:44 +0000 (GMT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc13) with ESMTP id <200406152322410160083sv8e>; Tue, 15 Jun 2004 23:22:42 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA50793; Tue, 15 Jun 2004 16:22:40 -0700 (PDT) Date: Tue, 15 Jun 2004 16:22:39 -0700 (PDT) From: Julian Elischer To: JG In-Reply-To: <5.2.0.9.2.20040614183523.015cdaa0@mail.ojoink.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org 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 23:22:45 -0000 On Mon, 14 Jun 2004, JG wrote: > > 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: erk! :-) As I suggested elsewhere: ----- quoted---- To check this you should try running systat -vmstat while noticing the slowdown and try see what is at 100%. if it turns out that you are NOT seeing disk or CPU limitted then the next step would be to take a snapshot of operations using ktrace -d -p (pid) for 20 second followe by krtace -C to turn it off again. then looking at the output may give an idea of what operations are taking too long, and what is waiting on what.. Julian