From: | Jim Nasby <jim(at)nasby(dot)net> |
---|---|
To: | Peter Geoghegan <pg(at)heroku(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Clock sweep not caching enough B-Tree leaf pages? |
Date: | 2014-04-21 22:26:37 |
Message-ID: | 53559B1D.80302@nasby.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 4/15/14, 1:15 PM, Peter Geoghegan wrote:
> On Tue, Apr 15, 2014 at 9:30 AM, Merlin Moncure<mmoncure(at)gmail(dot)com> wrote:
>> >There are many reports of improvement from lowering shared_buffers.
>> >The problem is that it tends to show up on complex production
>> >workloads and that there is no clear evidence pointing to problems
>> >with the clock sweep; it could be higher up in the partition locks or
>> >something else entirely (like the O/S). pgbench is also not the
>> >greatest tool for sniffing out these cases: it's too random and for
>> >large database optimization is generally an exercise in de-randomizing
>> >i/o patterns. We really, really need a broader testing suite that
>> >covers more usage patterns.
> I find it quite dissatisfying that we know so little about this.
This is an area where additional stats gathering would be very valuable. We're running 8G buffers on 512G servers because bumping it up hurt performance, but we have no clue why. Was it due to buffer pins? How many times the clock had to sweep to find a victim? Something else entirely? No idea... :(
--
Jim C. Nasby, Data Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2014-04-21 22:38:41 | Re: Clock sweep not caching enough B-Tree leaf pages? |
Previous Message | Jim Nasby | 2014-04-21 22:08:45 | Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD |