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 <pryzby@xxxxxxxxxxxxx> 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.
