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