Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 421042E00A6 for ; Wed, 26 Mar 2008 18:55:09 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 19345-07 for ; Wed, 26 Mar 2008 18:55:00 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from h07.llord.com (unknown [195.140.142.194]) by postgresql.org (Postfix) with ESMTP id 1CA8D2E004D for ; Wed, 26 Mar 2008 18:55:05 -0300 (ADT) Received: from par69-8-88-161-102-87.fbx.proxad.net ([88.161.102.87] helo=apollo13.peufeu.com) by h07.llord.com with esmtpa (Exim 4.68) (envelope-from ) id 1JedaG-0000Fy-U4; Wed, 26 Mar 2008 22:55:01 +0100 To: "p prince" , pgsql-performance@postgresql.org Subject: Re: how can a couple of expensive queries drag my system down? From: PFC Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <9722e78e0803261248g3305c2b9yfd5cfd528a505150@mail.gmail.com> Content-Transfer-Encoding: 7bit Date: Wed, 26 Mar 2008 22:58:16 +0100 Message-ID: In-Reply-To: <9722e78e0803261248g3305c2b9yfd5cfd528a505150@mail.gmail.com> User-Agent: Opera Mail/9.24 (Linux) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - h07.llord.com X-AntiAbuse: Original Domain - postgresql.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - peufeu.com X-Source: X-Source-Args: X-Source-Dir: X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=1.138 tagged_above=0 required=5 tests=AWL=1.038, RDNS_NONE=0.1 X-Spam-Level: * X-Archive-Number: 200803/496 X-Sequence-Number: 29450 > is this 'normal'? (loaded question I know) Depends. If you are on the edge, disk-wise, yes a big fat query can push it over and make it fall. > Should I be looking to offload expensive reporting queries to read-only > replicants of my database? You could do this, especially if the heavy queries involve reading gigabytes of data from disk (as reporting queries like to do). In that case, you can even use a cheap machine with cheap disks for the slave (even striped RAID) since data is duplicated anyway and all that matters is megabytes/second, not IOs/second. > Is this a symptom of slow disk? vmstat will tell you this. If iowait time goes through the roof, yes it's disk bound. If cpu use goes 100%, then it's cpu bound. > imporoperly tuned postgres settings? bad Also possible, you can try EXPLAIN of the problematic queries. > choice of OS, hardware, storage? Depends on how your SAN handles load. No idea about that. > Is this a sign of disk contention? Most probable. > How does CPU load come into play? With 8 CPUs, less likely. (Your problem query can swamp at most 1 CPU, so if the machine grinds with still 7 other cores available for the usual, it probably isn't cpu-bound)