X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id B49EF11F6661 for ; Thu, 13 Apr 2006 11:48:51 -0300 (ADT) X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Score: 0.178 X-Spam-Level: X-Spam-Status: No, score=0.178 required=5 tests=[AWL=-0.011, MISSING_HEADERS=0.189] Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id zEQGax5FqwHz for ; Thu, 13 Apr 2006 11:48:30 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from fon.nation-net.com (fon.nation-net.com [194.24.251.1]) by postgresql.org (Postfix) with ESMTP id 7C29D11F665F for ; Thu, 13 Apr 2006 11:48:14 -0300 (ADT) Received: from fon.nation-net.com (localhost [127.0.0.1]) by fon.nation-net.com (Postfix) with ESMTP id 27C96136FC9 for ; Thu, 13 Apr 2006 15:48:14 +0100 (BST) Received: from [194.24.251.10] (bum.net [194.24.251.10]) by fon.nation-net.com (Postfix) with ESMTP id 13AF6136FBA for ; Thu, 13 Apr 2006 15:48:14 +0100 (BST) Message-ID: <443E6416.3070900@laterooms.com> Date: Thu, 13 Apr 2006 15:45:42 +0100 From: Gavin Hamill User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: pgsql-performance@postgresql.org Subject: Re: pg 8.1.3, AIX, huge box, painfully slow. References: <17613.1144451138@sss.pgh.pa.us> <1144661209.21409.131.camel@localhost.localdomain> <443A2856.6050905@laterooms.com> <26244.1144683345@sss.pgh.pa.us> In-Reply-To: <26244.1144683345@sss.pgh.pa.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP X-Archive-Number: 200604/301 X-Sequence-Number: 18385 Tom Lane wrote: >Gavin Hamill writes: > > >>would a simple "#define LWLOCK_PADDED_SIZE 128" be sufficient? >> >> > >Yeah, that's fine. > > OK I tried that but noticed no real improvement... in the interim I've installed Debian on the pSeries (using http://debian.gonicus.de/debian/dists/sarge/main/disks-powerpc/current/pseries/install.txt ) and using a simple load-test script - it picks a 'hotelsearch' select at random from a big file and just does a pg_query on that via PHP... Using apachebench with 10 clients gave a loadavg of about 10 after a few minutes, and the logs showed typical query times of 8 seconds. Again, no disk activity, normal context-switching, just full-out CPU usage... We're improving the quality + efficiency of the hotelsearch function all the time (Simon will certainly be able to vouch for its complexity) - am really uncertain what to do next tho! :/ Cheers, Gavin.