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 75FE6534C4
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Fri, 13 May 2005 12:23:32 -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 58750-02
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Fri, 13 May 2005 15:23:27 +0000 (GMT)
Received: from ebrsrv01.ebravo.it (host53-205.pool8534.interbusiness.it
	[85.34.205.53])
	by svr1.postgresql.org (Postfix) with ESMTP id E3CB55339C
	for <pgsql-performance@postgresql.org>;
	Fri, 13 May 2005 12:23:25 -0300 (ADT)
Received: from [192.168.11.103] ([192.168.11.103]) (authenticated)
	by ebrsrv01.ebravo.it (8.11.6/8.12.5) with ESMTP id j4DFNJY01682;
	Fri, 13 May 2005 17:23:19 +0200
Message-ID: <4284C661.4050406@streppone.it>
Date: Fri, 13 May 2005 17:23:13 +0200
From: Cosimo Streppone <cosimo@streppone.it>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: it, it-it, en-us, en
MIME-Version: 1.0
To: Mindaugas Riauba <mind@bi.lt>
Cc: 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-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, hits=0.05 tagged_above=0 required=5 tests=FORGED_RCVD_HELO
X-Spam-Level: 
X-Archive-Number: 200505/262
X-Sequence-Number: 12426

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?

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.

-- 
Cosimo