Re: lazy vxid locks, v1 - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: lazy vxid locks, v1
Date
Msg-id BANLkTi=qdxa-Hhrpf8KKCW3YbZPiv2cTKQ@mail.gmail.com
Whole thread Raw
In response to lazy vxid locks, v1  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: lazy vxid locks, v1
List pgsql-hackers
On Sun, Jun 12, 2011 at 2:39 PM, Robert Haas <robertmhaas@gmail.com> wrote:
...
>
> Profiling reveals that the system spends enormous amounts of CPU time
> in s_lock.  LWLOCK_STATS reveals that the only lwlock with significant
> amounts of blocking is the BufFreelistLock;

This is curious.  Clearly the entire working set fits in RAM, or you
wouldn't be getting number like this.  But does the entire working set
fit in shared_buffers?  If so, you shouldn't see any traffic on
BufFreelistLock once all the data is read in.  I've only seen
contention here when all data fits in OS cache memory but not in
shared_buffers.



Cheers,

Jeff


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Why polecat and colugos are failing to build back branches
Next
From: Andrew Dunstan
Date:
Subject: Re: Why polecat and colugos are failing to build back branches