Date: Wed, 9 Jun 2021 23:28:53 -0500
From: Justin Pryzby <pryzby@telsasoft.com>
To: Haseeb Khan <khanhaseeb92@gmail.com>
Cc: pgsql-performance@lists.postgresql.org
Subject: Re: Page File Size Reached Critical Threshold PostgreSQL V13
Message-ID: <20210610042853.GB16435@telsasoft.com>
References: <A78AAC7E-75F0-4B44-ADCF-BCE522228ABA@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <A78AAC7E-75F0-4B44-ADCF-BCE522228ABA@gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: 
 <https://www.postgresql.org/message-id/20210610042853.GB16435%40telsasoft.com>
Precedence: bulk

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.

Hi,

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.

-- 
Justin