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 3925653323 for ; Fri, 13 May 2005 12:41:50 -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 60959-09 for ; Fri, 13 May 2005 15:41:45 +0000 (GMT) Received: from ns1.bi.lt (ns.bi.lt [213.226.131.131]) by svr1.postgresql.org (Postfix) with ESMTP id 029EB52A55 for ; Fri, 13 May 2005 12:41:44 -0300 (ADT) Received: from B027543 (inet.bee.lt [213.226.131.30]) by ns1.bi.lt (8.12.11/8.12.11) with SMTP id j4DFfhTV016654; Fri, 13 May 2005 18:41:43 +0300 Message-ID: <02f901c557d2$43517e10$f20214ac@bite.lt> From: "Mindaugas Riauba" To: "Cosimo Streppone" Cc: References: <01cc01c557ba$a4fdb0b0$f20214ac@bite.lt> <23217.1115991763@sss.pgh.pa.us> <022901c557c5$73df1220$f20214ac@bite.lt> <4284C661.4050406@streppone.it> Subject: Re: PostgreSQL strugling during high load Date: Fri, 13 May 2005 18:41:43 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1257" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.207 tagged_above=0 required=5 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: X-Archive-Number: 200505/263 X-Sequence-Number: 12427 > >>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? > > I've seen that happen when you're placing (explicitly or > *implicitly*) locks on the records you're trying to update/delete. > > If you're willing to investigate, `pg_locks' system view holds > information about db locks. Hm. Yes. Number of locks varies quite alot (10-600). Now what to investigate further? We do not use explicit locks in our functions. We use quite simple update/delete where key=something; Some sample (select * from pg_locks order by pid) is below. Thanks, Mindaugas | | 584302172 | 11836 | ExclusiveLock | t 17236 | 17230 | | 11836 | AccessShareLock | t 17236 | 17230 | | 11836 | RowExclusiveLock | t 127103 | 17230 | | 11836 | RowExclusiveLock | t 127106 | 17230 | | 11836 | RowExclusiveLock | t 127109 | 17230 | | 11836 | AccessShareLock | t 127109 | 17230 | | 11836 | RowExclusiveLock | t 127109 | 17230 | | 11837 | AccessShareLock | t 127109 | 17230 | | 11837 | RowExclusiveLock | t 17236 | 17230 | | 11837 | AccessShareLock | t 17236 | 17230 | | 11837 | RowExclusiveLock | t 127106 | 17230 | | 11837 | RowExclusiveLock | t 127103 | 17230 | | 11837 | RowExclusiveLock | t | | 584302173 | 11837 | ExclusiveLock | t 127103 | 17230 | | 11838 | RowExclusiveLock | t 17236 | 17230 | | 11838 | RowExclusiveLock | t 127109 | 17230 | | 11838 | RowExclusiveLock | t | | 584302174 | 11838 | ExclusiveLock | t 17285 | 17230 | | 11838 | AccessShareLock | t 17251 | 17230 | | 11838 | AccessShareLock | t 130516 | 17230 | | 11838 | AccessShareLock | t 127106 | 17230 | | 11838 | RowExclusiveLock | t 17278 | 17230 | | 11838 | AccessShareLock | t