Re: Changing shared_buffers without restart

Поиск
Список
Период
Сортировка
От Dmitry Dolgov
Тема Re: Changing shared_buffers without restart
Дата
Msg-id naninbnpras544vtq5grxxkxnfk7fvdkbikbrkxsexhl64g3yv@pcbgxawejoxe
обсуждение исходный текст
Ответ на Re: Changing shared_buffers without restart  (Jim Nasby <jnasby@upgrade.com>)
Список pgsql-hackers
> On Mon, Jul 14, 2025 at 05:55:13PM -0500, Jim Nasby wrote:
>
> Finally, while shared buffers is the most visible target here, there are
> other shared memory settings that have a *much* smaller surface area, and
> in my experience are going to be much more valuable from a tuning
> perspective; notably wal_buffers and the MXID SLRUs (and possibly CLOG and
> subtrans). I say that because unless you're running a workload that
> entirely fits in shared buffers, or a *really* small shared buffers
> compared to system memory, increasing shared buffers quickly gets into
> diminishing returns. But since the default size for the other fixed sized
> areas is so much smaller than normal values for shared_buffers, increasing
> those areas can have a much, much larger impact on performance. (Especially
> for something like the MXID SLRUs.) I would certainly consider focusing on
> one of those areas before trying to tackle shared buffers.

That's an interesting idea, thanks for sharing. The reason I'm
concentrating on shared buffers is that it was frequently called out as
a problem when trying to tune PostgreSQL automatically. In this context
shared buffers is usually one of the most impactful knobs, yet one of
the most painful to manage as well. But if the amount of complexity
around resizable shared buffers will be proved unsurmountable, yeah, it
would make sense to consider simpler targets using the same mechanism.



В списке pgsql-hackers по дате отправления: