Re: LWLOCK_STATS

Satoshi Nagayasu <snaga@uptime.jp>

From: "Satoshi Nagayasu / Uptime Technologies, LLC." <snaga@uptime.jp>
To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@postgresql.org
Date: 2012-01-07T14:02:37Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Take fewer snapshots.

  2. Various micro-optimizations for GetSnapshopData().

2012/01/07 16:58, Heikki Linnakangas wrote:
> On 07.01.2012 00:24, Robert Haas wrote:
>> It's been a while since I did any testing with LWLOCK_STATS defined,
>> so I thought it might be about time to do that again and see how
>> things look. Here's how they looked back in July:
>>
>> http://archives.postgresql.org/pgsql-hackers/2011-07/msg01373.php
>
> Interesting.
>
> A couple of weeks ago I wrote a little patch that's similar to LWLOCK_STATS, but it prints out % of wallclock time that is spent acquiring, releasing, or waiting for a lock. I find that more useful than the counters.
>
> Here's the patch, I hope it's useful to others. It uses timer_create() and timer_settime(), so it probably won't work on all platforms, and requires linking with -lrt.

I have just written up a systemtap script to observe
lock statistics.

It shows acquire counts, wait counts and
total waiting time for each lwlock every 5 seconds.

Screenshot here:
http://twitpic.com/83p2cz

Is this useful for pg developers?

-- 
Satoshi Nagayasu <snaga@uptime.jp>
Uptime Technologies, LLC. http://www.uptime.jp