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 514B852A6F for ; Sun, 15 May 2005 23:26:26 -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 50223-01 for ; Mon, 16 May 2005 02:26:17 +0000 (GMT) Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by svr1.postgresql.org (Postfix) with ESMTP id 4B49652A3D for ; Sun, 15 May 2005 23:26:16 -0300 (ADT) Received: from ool-44c11fd8.dyn.optonline.net ([68.193.31.216] helo=[192.168.1.66]) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1DXVJ9-000Kat-2h; Sun, 15 May 2005 22:26:15 -0400 Message-ID: <428804EA.6080609@zeut.net> Date: Sun, 15 May 2005 22:26:50 -0400 From: "Matthew T. O'Connor" User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mindaugas Riauba Cc: Tom Lane , pgsql-performance@postgresql.org Subject: Re: PostgreSQL strugling during high load References: <01cc01c557ba$a4fdb0b0$f20214ac@bite.lt> <23217.1115991763@sss.pgh.pa.us> <022901c557c5$73df1220$f20214ac@bite.lt> In-Reply-To: <022901c557c5$73df1220$f20214ac@bite.lt> Content-Type: text/plain; charset=windows-1257; format=flowed Content-Transfer-Encoding: 7bit X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 68.193.31.216 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: zeut X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests= X-Spam-Level: X-Archive-Number: 200505/294 X-Sequence-Number: 12458 Mindaugas Riauba wrote: >>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. >> >> > > It looks like that not only vacuum causes our problems. vacuum_cost >seems to lower vacuum impact but we are still noticing slow queries "storm". >We are logging queries that takes >2000ms to process. > And there is quiet periods and then suddenly 30+ slow queries appears in >log within the same second. What else could cause such behaviour? WAL log >switch? One WAL file seems to last <1 minute. > > How long are these quite periods? Do the "strom" periods correspond to pg_autovacuum loops? I have heard from one person who had LOTS of databases and tables that caused the pg_autovacuum to create a noticable load just updateing all its stats. The solution in that case was to add a small delay insidet the inner pg_autovacuum loop.