X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 9122353A9B for ; Fri, 13 May 2005 14:33:30 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 82331-09 for ; Fri, 13 May 2005 17:33:24 +0000 (GMT) Received: from priv-edtnes56.telusplanet.net (outbound01.telus.net [199.185.220.220]) by svr1.postgresql.org (Postfix) with ESMTP id E2EAA53A36 for ; Fri, 13 May 2005 14:33:22 -0300 (ADT) Received: from localhost ([199.185.220.240]) by priv-edtnes56.telusplanet.net (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20050513173323.QOMD21244.priv-edtnes56.telusplanet.net@localhost>; Fri, 13 May 2005 11:33:23 -0600 Received: from 209.17.183.249 ( [209.17.183.249]) as user a3a18850@192.168.200.1 by webmail.telus.net with HTTP; Fri, 13 May 2005 10:33:22 -0700 Message-ID: <1116005602.4284e4e28869e@webmail.telus.net> Date: Fri, 13 May 2005 10:33:22 -0700 From: Mischa Sandberg To: Tom Lane Cc: Mindaugas Riauba , pgsql-performance@postgresql.org Subject: Re: PostgreSQL strugling during high load References: <01cc01c557ba$a4fdb0b0$f20214ac@bite.lt> <23217.1115991763@sss.pgh.pa.us> In-Reply-To: <23217.1115991763@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1-cvs X-Originating-IP: 209.17.183.249 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=1.04 tagged_above=0 required=5 tests=AWL, DNS_FROM_RFC_POST, FORGED_RCVD_HELO X-Spam-Level: * X-Archive-Number: 200505/267 X-Sequence-Number: 12431 Quoting Tom Lane : > "Mindaugas Riauba" writes: > > ... So contents of database changes very fast. Problem is that > when > > pg_autovacuum does vacuum those changes slows down too much. > > The "vacuum cost" parameters can be adjusted to make vacuums fired > by pg_autovacuum less of a burden. I haven't got any specific > numbers > to suggest, but perhaps someone else does. I solved one problem by cranking sleep scaling to -S 20. It made pg_autovacuum back off longer during extended periods of heavy disk-intensive query activity. Our update activity is near-constant insert rate, then once or twice a day, massive deletes. -- Dreams come true, not free.