X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (mx2.hub.org [200.46.204.254]) by postgresql.org (Postfix) with ESMTP id 9873911F6770 for ; Thu, 20 Apr 2006 12:16:57 -0300 (ADT) X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 required=5 tests=[AWL=0.075, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from postgresql.org ([200.46.204.71]) by localhost (mx2.hub.org [200.46.204.254]) (amavisd-new, port 10024) with ESMTP id PrlDJNFYmmiR for ; Thu, 20 Apr 2006 12:16:52 -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 31A2511F663F for ; Thu, 20 Apr 2006 12:16:50 -0300 (ADT) Received: from fon.nation-net.com (localhost [127.0.0.1]) by fon.nation-net.com (Postfix) with ESMTP id CE2631371E6 for ; Thu, 20 Apr 2006 16:16:44 +0100 (BST) Received: from [194.24.251.10] (bum.net [194.24.251.10]) by fon.nation-net.com (Postfix) with ESMTP id 95908136AA3 for ; Thu, 20 Apr 2006 16:16:44 +0100 (BST) Message-ID: <4447A52D.90804@laterooms.com> Date: Thu, 20 Apr 2006 16:13:49 +0100 From: Gavin Hamill User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: IBM pSeries - overrated bucket of crud? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP X-Archive-Number: 200604/454 X-Sequence-Number: 18538 Hi again :) This is a follow-up to the mega thread which made a Friday night more interesting [1] - the summary is various people thought there was some issue with shared memory access on AIX. I then installed Debian (kernel 2.6.11) on the 8-CPU p650 (native - no LPAR) and saw just as woeful performance. Now I've had a chance to try a 2-CPU dualcore Opteron box, and it *FLIES* - the 4-way machine sits churning through our heavy 'hotelsearch' function at ~400ms per call. Basically, this pSeries box is available until Monday lunchtime if any pg devel wants to pop in, run tests, mess around since I am convinced that the hardware itself cannot be this poor - it has to be some failing of pg when mixed with our dataset / load pattern. e.g. If I run 'ab -n 200 -c 4 -k http://localhost/test.php [2] with pg_connect pointed at the pSeries, it turns in search times of ~3500ms with loadavg of 4. The same test with pg_connect pointed at the dual-Opteron turns in ~300ms searches, with loadavg of 3.5 .. something is very very wrong with the pSeries setup :) If I crank up the heat and run apachebench with 10 hammering clients instead of 4, the differences become even more stark.. pSeries: 5000-15000ms, loadavg 9.. Opteron ~3000ms, loadavg 8. 90% of queries on the Opteron conclude in under 4000ms, which maxes out at 6.5 searches per second. The pSeries manages 0.9 searches per second. (!) Databases on both machines have seen a VACUUM FULL and VACUUM ANALYZE before testing, and have near-identical postgresql.conf's. (the pSeries has twice the RAM) This post is not intended to be whining that 'pg is crap on pSeries!' - I'm trying to make a resource available (albeit for a short time) to help fix a problem that will doubtless affect others in future - for certain we're never going midrange again! :O Cheers, Gavin. [1] http://archives.postgresql.org/pgsql-performance/2006-04/msg00143.php [2] Trivial script which does a pg_connect, runs a random hotelsearch and exits.