Date: Mon, 24 May 2004 01:15:47 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Petri Helenius <pete@he.iki.fi> Cc: freebsd-threads@freebsd.org Subject: Re: Why is MySQL nearly twice as fast on Linux? Message-ID: <Pine.NEB.3.96L.1040524011024.33071C-100000@fledge.watson.org> In-Reply-To: <40B1053F.6080604@he.iki.fi>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040524011024.33071C-100000>