Horton

Re: lazy vxid locks, v1

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>
Cc: Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@postgresql.org
Date: 2011-06-13T14:29:28Z
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. Avoid extra system calls to block SIGPIPE if the platform provides either

Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
> On 06/12/2011 11:39 PM, Robert Haas wrote:
>> Profiling reveals that the system spends enormous amounts of CPU time
>> in s_lock.  

> just to reiterate that with numbers - at 160 threads with both patches
> applied the profile looks like:

> samples  %        image name               symbol name
> 828794   75.8662  postgres                 s_lock

Do you know exactly which spinlocks are being contended on here?
The next few entries

> 51672     4.7300  postgres                 LWLockAcquire
> 51145     4.6817  postgres                 LWLockRelease
> 17636     1.6144  postgres                 GetSnapshotData

suggest that it might be the ProcArrayLock as a result of a huge amount
of snapshot-fetching, but this is very weak evidence for that theory.

			regards, tom lane