From owner-freebsd-questions@FreeBSD.ORG Fri Aug 29 07:52:15 2008 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C343B1065683 for ; Fri, 29 Aug 2008 07:52:15 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B704C8FC0C; Fri, 29 Aug 2008 07:52:14 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <48B7AAA9.8000706@FreeBSD.org> Date: Fri, 29 Aug 2008 09:52:09 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: "Paul A. Procacci" References: <48B7A67F.8050204@datapipe.com> In-Reply-To: <48B7A67F.8050204@datapipe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Subject: Re: General Mysql Performance Question X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2008 07:52:15 -0000 Paul A. Procacci wrote: > My question is in reference to the 1st and 2nd graphs on this page. > While testing the performance of the databases given in this graph, the > one thing that sticks out is that when Mysql uses the myisam engine with > the ULE schedular, performance drops quite considerably regardless of > mysql version. The clearly shows ULE to perform worst at higher work > loads than 4BSD, at least in this one example. > > Now, I read that lockmgr code is still a work in progress, but I'm > unsure if that applies specifically to this specific problem that I'm > providing. What I'm hoping for quite frankly is a "yes, this is > because...." type of response. > > This isn't a problem per se, but rather a curiosity type of question. myisam has huge lock contention, so probably ULE is more efficiently scheduling the processes and increasing contention yet further, leading to a net drop of performance. That kind of thing is fairly common when you have a workload with high contention; if you improve performance at one bottleneck the performance at a later bottleneck can get worse. Performance will still be better on other workloads, or when further work improves the other bottlenecks. Kris