Re: lazy vxid locks, v1

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: lazy vxid locks, v1
Date: 2011-06-14 00:10:58
Message-ID: BANLkTi=qdxa-Hhrpf8KKCW3YbZPiv2cTKQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jun 12, 2011 at 2:39 PM, Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2011-06-14 00:19:05 Re: Why polecat and colugos are failing to build back branches
Previous Message Tom Lane 2011-06-14 00:05:55 Why polecat and colugos are failing to build back branches