Message-ID: <53428386.6040607@cs.utoronto.ca>
Date: Mon, 07 Apr 2014 06:52:54 -0400
From: Ryan Johnson <ryan.johnson@cs.utoronto.ca>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: SSI slows down over time
References: <5340BB09.5010101@cs.utoronto.ca> <534110B6.8020509@vmware.com>
In-Reply-To: <534110B6.8020509@vmware.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

On 06/04/2014 4:30 AM, Heikki Linnakangas wrote:
> On 04/06/2014 05:25 AM, Ryan Johnson wrote:
>> I've tried linux perf, but all it says is that lots of time is going to
>> LWLock (but callgraph tracing doesn't work in my not-bleeding-edge
>> kernel).
>
> Make sure you compile with the "-fno-omit-frame-pointer" flag.
Oh, right. Forgot about that. With -g in place, it shows 5% of time 
going to LWLockAcquire, virtually all of that in PredicateLockPage. 
However, top reports only 50% utilization, so I'd *really* like to have 
stack traces and "counts" for stack traces the worker thread spends its 
time blocked in. I don't know a way to get that out of perf, though. 
It's near-trivial to do in dtrace, but unfortunately I don't have a 
Solaris or BSD machine handy.

Does pgsql give a way to trace latencies due to LWLock?

Thanks,
Ryan


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance