Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id F059764FCF9 for ; Tue, 16 Sep 2008 14:10:08 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 85548-05 for ; Tue, 16 Sep 2008 14:10:03 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by postgresql.org (Postfix) with ESMTP id CFA2864FCF2 for ; Tue, 16 Sep 2008 14:10:02 -0300 (ADT) Received: by rv-out-0506.google.com with SMTP id b25so3617708rvf.43 for ; Tue, 16 Sep 2008 10:10:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=4NW1+lafPfxm2srZTMmUP70rVYEEkdo4mmfRgmR8tro=; b=bMPpJamWFrUoFbAXpGchnUyTqPK/qoD9Itnefv0KPTq4Qq8wcWJgFz1lGR5J7Oxw2L JzAzfGywyCaZnnObAC6H7Ap7t066RdvoxhHQ5w5Yd9gNaIIZaaZxidjbeGcVzeVskGna XV7FHoXfJ9UZedAdH+8wgcNzhXX5KlP9GvVdA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=tEjtR+ujAHOTWGifYJZwwuFiyzGNTU2ogEZCHY33rsvxQrf4XL0zcQBCs9GuPZpVh9 hBammUIJrmmDsQxsY6fVqEDoLWIBtqWSCfuds5nD0ylRoQN8vFRfU201hg7fd08brUNu 9CXs68NfOJWOLRTPxdYEPyCi93ZR3hq8MYcYI= Received: by 10.141.13.13 with SMTP id q13mr5876355rvi.11.1221585001530; Tue, 16 Sep 2008 10:10:01 -0700 (PDT) Received: by 10.141.74.11 with HTTP; Tue, 16 Sep 2008 10:10:01 -0700 (PDT) Message-ID: Date: Tue, 16 Sep 2008 11:10:01 -0600 From: "Scott Marlowe" To: Mauri.Sahlberg@claymountain.com Subject: Re: Help request: how to tune performance? Cc: pgsql-admin@postgresql.org In-Reply-To: <1221553908.3410.11.camel@fault.in.tuolla.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1221553908.3410.11.camel@fault.in.tuolla.net> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200809/162 X-Sequence-Number: 30255 On Tue, Sep 16, 2008 at 2:31 AM, Mauri Sahlberg wrote: > Hi, > > We just upgraded Best Practical's RT from 3.6 to 3.81 and gave the > database completely own machine. And the users still complain that it is > dog slow. Moved up from below: > Version : 8.1.11 Vendor: CentOS So, you built it its own machine, but you didn't upgrade to at least 8.2? Last place I worked we ran rt 3.6.1 and got a noticeable performance boost from switching to 8.2 but the only thing that was ever really slow was viewing the rather large approval queue. > :-( I installed pg_top and it seems that at the beginning of > the ticket display RT-issues a query that eats everything the database > has. Query is as follows: > > SELECT DISTINCT main.* FROM Users main CROSS JOIN ACL ACL_2 JOIN > Principals Principals_1 ON ( Principals_1.id = main.id ) JOIN > CachedGroupMembers CachedGroupMembers_3 ON > ( CachedGroupMembers_3.MemberId = Principals_1.id ) WHERE > (Principals_1.Disabled = '0') AND (ACL_2.PrincipalId = > CachedGroupMembers_3.GroupId) AND (Principals_1.id != '1') AND > (ACL_2.PrincipalType = 'Group') AND (Principals_1.PrincipalType = > 'User') AND (ACL_2.RightName = 'OwnTicket') AND ((ACL_2.ObjectType = > 'RT::Queue' AND ACL_2.ObjectId = 18) OR (ACL_2.ObjectType = > 'RT::System')) ORDER BY main.Name ASC Please post the output of explain analyze as an attachment. explain is only half the answer. > Is there something I can do to improve performance with tuning something > on postgresql.conf? Or adding/dropping indexes? What I read from that > query plan is that the single most expensive thing is sequential scan on > Principals. Principals already has indexes for both id and object.id! Possibly. explain analyze will help you identify where stats are wrong. sometimes just cranking the stats target on a few columns and re-analyzing gets you a noticeable performance boost. It's cheap and easy. When the estimated and actual number of rows are fairly close, then look for the slowest thing and see if an index can help. What have to already done to tune the install? shared_buffers, work_mem, random_page_cost, effective_cache_size. Is your db bloating during the day? Why no try 8.3 on this? Are you running on a single SATA hard drive? How big's the database directory? I'm guessing from your top output that the db is about 500 meg or so. it should all fit in memory.