From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jordan Hurwich <jhurwich(at)pulsasensors(dot)com> |
Cc: | Samed YILDIRIM <samed(at)reddoc(dot)net>, pgsql-performance(at)lists(dot)postgresql(dot)org, Gautam Bellary <gautam(at)pulsasensors(dot)com> |
Subject: | Re: Increased iowait and blk_read_time with higher shared_buffers |
Date: | 2022-12-14 18:27:23 |
Message-ID: | 2784235.1671042443@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Jordan Hurwich <jhurwich(at)pulsasensors(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jordan Hurwich | 2022-12-14 18:32:34 | Re: Increased iowait and blk_read_time with higher shared_buffers |
Previous Message | Jordan Hurwich | 2022-12-14 18:12:16 | Re: Increased iowait and blk_read_time with higher shared_buffers |