Message-ID: <47874EE8.2050406@comgate.cz>
Date: Fri, 11 Jan 2008 12:11:36 +0100
From: Jakub Ouhrabka <kuba@comgate.cz>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-performance@postgresql.org
Subject: Re: Linux/PostgreSQL scalability issue - problem with 8
 cores
References: <flii57$748$1@news.hub.org> <7083.1199379570@sss.pgh.pa.us>
	<477D1D59.7050002@comgate.cz> <4782063C.7070105@comgate.cz>
	<26502.1199745090@sss.pgh.pa.us> <4782AB4D.8010009@comgate.cz>
	<27655.1199750492@sss.pgh.pa.us> <47836A4C.5080707@comgate.cz>
	<10713.1199813111@sss.pgh.pa.us>
In-Reply-To: <10713.1199813111@sss.pgh.pa.us>
Content-Type: text/plain; charset=windows-1250; format=flowed
Content-Transfer-Encoding: 7bit

Hi Tom,

 > I doubt we'd risk destabilizing 8.3 at this point, for a problem that
 > affects so few people; let alone back-patching into 8.2.

understand.

 > OK, that confirms the theory that it's sinval-queue contention.

We'we tried hard to identify what's the cause of filling sinval-queue. 
We went through query logs as well as function bodies stored in the 
database. We were not able to find any DDL, temp table creations etc.

We did following experiment: stop one of our clients, so there started 
to be queue of events (aka rows in db) for it to process. Then we 
started the client again, it started processing the queue - that means 
calling simple selects, updates and complex plpgsql function(s). And at 
this moment, the spike started even it shouldn't start to meet usual 
periodicity. It's consistent. We are pretty sure that this client is not 
doing any DDL...

What should we look for to find the cause?

Thanks for any hints,

Kuba