Re: Increased iowait and blk_read_time with higher shared_buffers - Mailing list pgsql-performance

From Jordan Hurwich
Subject Re: Increased iowait and blk_read_time with higher shared_buffers
Date
Msg-id CAJKqsjtUrMUObDhR-SuvubYtT+k0Qc6jBsA28WOhSt8+kSwj2Q@mail.gmail.com
Whole thread Raw
In response to Re: Increased iowait and blk_read_time with higher shared_buffers  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
Thanks Tom, that makes a lot of sense. Given we're seeing low iowait and blk_read_time at 4GB shared_buffers, sounds like we should just declare victory here and be happy with that setting?

On Wed, Dec 14, 2022 at 10:27 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Jordan Hurwich <jhurwich@pulsasensors.com> writes:
> I'm familiar with the article you linked to, and part of my surprise is
> that with these 32GB RAM machines we're seeing better performance at 12.5%
> (4GB) than the commonly recommended 25% (8GB) of system memory for
> shared_buffers. Your notes about disk read stats from Postgres potentially
> actually representing blocks read from the OS cache make sense, I just
> imagined that Postgres would be better at managing the memory when it was
> dedicated to it via shared_buffers than the OS (obviously with some point
> of diminishing returns); and I'm still hoping there's some Postgres
> configuration change we can make that enables better performance through
> improved utilization of shared_buffers at the commonly recommended 25% of
> system memory.

Keep in mind that 25% was never some kind of golden number.  It is
a rough rule of thumb that was invented for far smaller machines than
what you're talking about here.

                        regards, tom lane

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: Increased iowait and blk_read_time with higher shared_buffers
Next
From: Samed YILDIRIM
Date:
Subject: Re: Increased iowait and blk_read_time with higher shared_buffers