From owner-freebsd-stable@FreeBSD.ORG Fri Jan 11 17:15:11 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5755316A41A for ; Fri, 11 Jan 2008 17:15:11 +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 9D9A313C43E; Fri, 11 Jan 2008 17:15:10 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <4787A41C.70100@FreeBSD.org> Date: Fri, 11 Jan 2008 18:15:08 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Krassimir Slavchev References: <476A5EE1.9000003@bulinfo.net> <476FF662.6050604@FreeBSD.org> <477BB7C0.3060603@bulinfo.net> In-Reply-To: <477BB7C0.3060603@bulinfo.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Subject: Re: Performance! [SOLVED] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2008 17:15:11 -0000 Krassimir Slavchev wrote: >> >> I have read all related threads about performance problems with multi >> core systems but still have no idea what to do to make thinks better. >> Below are results of testing postgresql on HP DL380G5 using sysbench. >> The results are comparable to: >> http://blog.insidesystems.net/articles/2007/04/11/postgresql-scaling-on-6-2-and-7-0 >> >> but the same tests running on the same hardware using Linux (kernel >> 2.6.18-53.1.4.el5 SMP x86_64) are very different. >> PostgreSQL is tuned equal. Just to summarize some discussion we had off-list, this problem is now resolved. It turned out to have two causes: 1) sysbench on linux was defaulting to using a unix domain socket to communicate with pgsql, but FreeBSD was using TCP to 127.0.0.1. TCP has much more overhead so performance was lower. Using --pgsql-host="" in sysbench is the fix for this. 2) pgsql was not compiled with thread support enabled, which caused lots of bad interactions with the threaded sysbench client. This probably would have caused data corruption too (silent in this case because nothing was checking the query responses). The fix was to recompile the pgsql client and server with the THREADSAFE option enabled. Krassimir reports that with these two fixes, the standard 7.0 kernel has performance: #threads transactions/sec 1 755 8 7129 40 6580 100 6768 compared to Linux: Linux (2.6.18) #threads #transactions/sec 1 693 5 3539 10 5789 20 5791 40 5661 60 5517 80 5401 100 5319 Linux (2.6.23) #threads #transactions/sec 1 740 5 2675 10 6486 20 6893 40 6623 60 6623 80 6522 100 6417 I think this is a satisfactory resolution :) Kris