Re: lazy vxid locks, v1

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>

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

Cc: Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>, pgsql-hackers@postgresql.org

Date: 2011-06-13T15:06:46Z

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 →

Avoid extra system calls to block SIGPIPE if the platform provides either
- cea80e726edd 9.0.0 cited

On Mon, Jun 13, 2011 at 10:29 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

I don't know for sure what is happening on Stefan's system, but I did
post the results of some research on this exact topic in my original
post.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company