Received: from localhost (unknown [200.46.204.184])
	by postgresql.org (Postfix) with ESMTP id 4E9432E3016
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Mon,  7 Jan 2008 11:12:57 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024)
	with ESMTP id 37162-03 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Mon,  7 Jan 2008 11:12:36 -0400 (AST)
Received: from lists.commandprompt.com (host-159.commandprompt.net
	[207.173.203.159])
	by postgresql.org (Postfix) with ESMTP id A74372E2FCD
	for <pgsql-performance@postgresql.org>;
	Mon,  7 Jan 2008 11:12:43 -0400 (AST)
Received: from perhan.alvh.no-ip.org (200-126-101-79.bk7-dsl.surnet.cl
	[200.126.101.79]) (authenticated bits=0)
	by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id m07FCgst018043
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 7 Jan 2008 07:12:45 -0800
Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000)
	id 9713A47C8C; Mon,  7 Jan 2008 12:12:34 -0300 (CLST)
Date: Mon, 7 Jan 2008 12:12:34 -0300
From: Alvaro Herrera <alvherre@commandprompt.com>
To: Jakub Ouhrabka <kuba@comgate.cz>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-performance@postgresql.org
Subject: Re: Linux/PostgreSQL scalability issue - problem with 8
	cores
Message-ID: <20080107151234.GG4723@alvh.no-ip.org>
References: <flii57$748$1@news.hub.org> <7083.1199379570@sss.pgh.pa.us>
	<477D1D59.7050002@comgate.cz> <4782063C.7070105@comgate.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4782063C.7070105@comgate.cz>
User-Agent: Mutt/1.5.17 (2007-11-01)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0
	(lists.commandprompt.com [207.173.203.159]);
	Mon, 07 Jan 2008 07:12:45 -0800 (PST)
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200801/17
X-Sequence-Number: 28256

Jakub Ouhrabka wrote:

> We've tried several times to get stacktrace from some of the running 
> backends during spikes, we got always this:
>
> 0x00002b005d00a9a9 in semop () from /lib/libc.so.6
> #0  0x00002b005d00a9a9 in semop () from /lib/libc.so.6
> #1  0x000000000054fe53 in PGSemaphoreLock (sema=0x2b00a04e5090, 
> interruptOK=0 '\0') at pg_sema.c:411
> #2  0x0000000000575d95 in LWLockAcquire (lockid=SInvalLock, 
> mode=LW_EXCLUSIVE) at lwlock.c:455
> #3  0x000000000056fbfe in ReceiveSharedInvalidMessages 
> (invalFunction=0x5e9a30 <LocalExecuteInvalidationMessage>,
>    resetFunction=0x5e9df0 <InvalidateSystemCaches>) at sinval.c:159
> #4  0x0000000000463505 in StartTransactionCommand () at xact.c:1439
> #5  0x000000000056fa4b in ProcessCatchupEvent () at sinval.c:347
> #6  0x000000000056fb20 in CatchupInterruptHandler 
> (postgres_signal_arg=<value optimized out>) at sinval.c:221
> #7  0x00002b005cf6f110 in killpg () from /lib/libc.so.6
> #8  0x0000000000000000 in ?? ()

Perhaps it would make sense to try to take the "fast path" in
SIDelExpiredDataEntries with only a shared lock rather than exclusive.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.