On Thu, Jun 10, 2021 at 11:41:09AM +0500, Haseeb Khan wrote: > You mean, So should I request for to increase the System Ram from 32 Gb to 64 > Gb and keep the same parameter setting.Is it ?
No - I don't know how large your DB is, or the other question that I asked. So I can't possibly make a suggestion to add RAM. But I do know that "half" is the worst possible setting for many databases. I suggest to provide some more information, and we can try to suggest a better configuration. https://wiki.postgresql.org/wiki/Slow_Query_Questions On 10-Jun-2021, at 9:28 AM, Justin Pryzby <pry...@telsasoft.com> wrote: > > On Thu, Jun 10, 2021 at 05:45:45AM +0500, Haseeb Khan wrote: > >> We have installed PostgreSQL V13 on window’s server 2016, where we kept > >> the Ram of the Server is 32 GB and disk size is 270 GB.Later we faced some > >> performance issues regarding the database, after deep dive into it we came > >> up and increased the Shared buffer size to 16 Gb. After the changed I am > >> not sure we are facing that Page file Size reached to critical threshold. > >> Currently the Page File size is 9504MB. > > > > How large is your DB ? (Or the "active set" of the DB, if parts of it are > > accessed infrequently). > > > > What was the original performance issue that led you to increase > > shared_buffers ? > > > > You've set shared_buffers to half of your RAM, which may be a "worst case" > > setting, since everything that's read into shared_buffers must first be read > > into the OS cache. So it may be that many blocks are cached twice, rather > > than > > relying on a smaller shared_buffers only for the "hottest" blocks, and the > > larger OS cache for everything else. > > > > There are exceptions to the guideline - for example, if your DB is 23 GB in > > size, it might make sense to have the entire thing in 24GB OF > > shared_buffers. > > But most DB don't need to fit in shared_buffers, and you shouldn't make > > that a > > goal, unless you can measure a performance benefit.
