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 A75EA11F6600 for ; Fri, 7 Apr 2006 19:57:02 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 91020-06 for ; Fri, 7 Apr 2006 19:56:57 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mail.mi8.com (d01gw02.mi8.com [63.240.6.46]) by postgresql.org (Postfix) with ESMTP id B16D111F662C for ; Fri, 7 Apr 2006 19:56:59 -0300 (ADT) Received: from 172.16.1.110 by mail.mi8.com with ESMTP (- Welcome to Mi8 Corporation www.Mi8.com (D2)); Fri, 07 Apr 2006 18:56:54 -0400 X-Server-Uuid: 7829E76E-BB9E-4995-8473-3C0929DF7DD1 Received: from MI8NYCMAIL06.Mi8.com ([172.16.1.160]) by D01SMTP01.Mi8.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 18:56:54 -0400 Received: from 67.103.45.218 ([67.103.45.218]) by MI8NYCMAIL06.Mi8.com ( [172.16.1.219]) via Exchange Front-End Server mi8owa.mi8.com ( [172.16.1.106]) with Microsoft Exchange Server HTTP-DAV ; Fri, 7 Apr 2006 22:56:53 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Fri, 07 Apr 2006 15:56:52 -0700 Subject: Re: pg 8.1.3, AIX, huge box, painfully slow. From: "Luke Lonergan" To: "Gavin Hamill" , pgsql-performance@postgresql.org Message-ID: Thread-Topic: [PERFORM] pg 8.1.3, AIX, huge box, painfully slow. Thread-Index: AcZakrRRJ4ZxhjkkROWmZZN4c+nUhwAA9rUM In-Reply-To: <20060407232759.45581362.gdh@laterooms.com> MIME-Version: 1.0 X-OriginalArrivalTime: 07 Apr 2006 22:56:54.0226 (UTC) FILETIME=[907BBB20:01C65A96] X-WSS-ID: 682831BC2XS41684920-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=1.349 required=5 tests=[AWL=0.096, RCVD_NUMERIC_HELO=1.253] X-Spam-Score: 1.349 X-Spam-Level: * X-Archive-Number: 200604/166 X-Sequence-Number: 18250 Gavin, On 4/7/06 3:27 PM, "Gavin Hamill" wrote: > 278774: __semop(15728650, 0x0FFFFFFFFFFF7E80, 1) = 0 > 155712: __semop(15728650, 0x0FFFFFFFFFFF5920, 1) = 0 > 278774: __semop(15728649, 0x0FFFFFFFFFFF6F10, 1) > 114914: __semop(15728649, 0x0FFFFFFFFFFF6A40, 1) = 0 = 0 > 114914: __semop(15728650, 0x0FFFFFFFFFFF61E0, 1) > 155712: __semop(15728650, 0x0FFFFFFFFFFF6850, 1) = 0 = 0 > 155712: __semop(15728650, 0x0FFFFFFFFFFF6890, 1) = 0 1 > 55712: __semop(15728650, 0x0FFFFFFFFFFF5920, 1) > 278774: __semop(15728650, 0x0FFFFFFFFFFF6F10, 1) > 155712: __semop(15728650, 0x0FFFFFFFFFFF6850, 1) = 0 = 0 > 278774: __semop(15728649, 0x0FFFFFFFFFFF7E40, 1) > 114914: __semop(15728649, 0x0FFFFFFFFFFF6A80, 1) = 0 = 0 > 278774: __semop(15728650, 0x0FFFFFFFFFFF7E80, 1) Seems like you're hitting a very small target in RAM with these semop calls. I wonder what part of the code is doing this - Tom would know better how to trace it, but the equivalent of oprofile output would be nice. The other thing that I'd like to see is an evaluation of the memory access latency of this machine from Register to RAM. I couldn't find a benchmarking tool that was UNIX friendly out there, maybe I'll write one real quick. I suspect this machine has a heinous latency and a storm of semops to the same spot of RAM might be a far worse performance problem on this machine than on others... - Luke