Skip site navigation (1) Skip section navigation (2)

Re: User concurrency thresholding: where do I look?

From: "Jignesh K(dot) Shah" <J(dot)K(dot)Shah(at)Sun(dot)COM>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-performance(at)postgresql(dot)org, Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Subject: Re: User concurrency thresholding: where do I look?
Date: 2007-07-20 20:51:39
Message-ID: 46A1205B.8010205@sun.com (view raw or flat)
Thread:
Lists: pgsql-performance
sorry..

The are solaris mutex locks used by the postgresql process.

What its saying is that there are holds/waits in trying to get locks 
which are locked at Solaris user library levels called from the  
postgresql functions:
For example both the following functions are hitting on the same mutex 
lock  0x10059e280  in Solaris Library call:
postgres`AllocSetDelete+0x98
postgres`AllocSetAlloc+0x1c4


I need to enable the DTrace probes on my builds

-Jignesh

Tom Lane wrote:
> "Jignesh K. Shah" <J(dot)K(dot)Shah(at)Sun(dot)COM> writes:
>   
>> Tom Lane wrote:
>>     
>>> So follow that up --- try to determine which lock is being contended
>>> for.  There's some very crude code in the sources that you can enable
>>> with -DLWLOCK_STATS, but probably DTrace would be a better tool.
>>>       
>
>   
>> Using plockstat -A -s 5 -p $pid
>>     
>
> I don't know what that is, but it doesn't appear to have anything to do
> with Postgres LWLocks or spinlocks, which are the locks I was thinking of.
> Try asking Robert Lor about this --- IIRC he had some dtrace probes to
> work with our locks.
>
> 			regards, tom lane
>   

In response to

Responses

pgsql-performance by date

Next:From: Tom LaneDate: 2007-07-20 20:57:34
Subject: Re: User concurrency thresholding: where do I look?
Previous:From: Tom LaneDate: 2007-07-20 20:16:01
Subject: Re: User concurrency thresholding: where do I look?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group