From owner-freebsd-threads@FreeBSD.ORG Sun May 23 22:16:12 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 B27A016A4CE for ; Sun, 23 May 2004 22:16:12 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 56FCF43D1D for ; Sun, 23 May 2004 22:16:12 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i4O5FlDE045716; Mon, 24 May 2004 01:15:47 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i4O5FlEm045713; Mon, 24 May 2004 01:15:47 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Mon, 24 May 2004 01:15:47 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Petri Helenius In-Reply-To: <40B1053F.6080604@he.iki.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE cc: Julian Elischer cc: freebsd-threads@freebsd.org Subject: Re: Why is MySQL nearly twice as fast on Linux? 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: Mon, 24 May 2004 05:16:12 -0000 On Sun, 23 May 2004, Petri Helenius wrote: > I find it hard to believe that the threading stuff would be seriously > broken since we do large processing with libkse and don=B4t have issues > with the performance. However I=B4m observing about 50000 context switche= s > but only 5000 syscalls a second. (I know it=B4s a different application > but also for 1500 queries a second 70000 syscalls sounds excessive).=20 Another thing that would be interesting to know is where the user processes are doing most of their waiting. Unfortunately, the mechanism I would use to derive this is a bit complicated. Not sure if you want to get into it or not, but... here's what I would do: I'd modify the KTR(4) tracing in msleep() to track the time slept and generate a log message indicating the wait channel, wait time, and process information. I'd set up a KTR and maybe ALQ trace to log a set of MySQL traces over a five second window during the benchmark. I'd dump the log records and then do a bit of statistical analysis to look at what the wait time distribution for various wait channels is. This might give a hint as to what in the kernel is being "waited" for. A nice pretty graph or the like for each wait channel. My recollection of previous posts in this thread is that the system is relatively idle, but did we determine what behavior was being seen on UP relating to CPU consumption? In particular, % user/system/interrupt/...=20 time for the CPU during a sustained benchmark run? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research