Thread: BUG #16314: Database Cache Hit Ratio (Warning)

The following bug has been logged on the website:

Bug reference:      16314
Logged by:          Rajiv Ranjan
Email address:      rajiv.mca08@gmail.com
PostgreSQL version: 9.6.0
Operating system:   Red Hat Enterprise Linux Server release 7.6 (Maip)
Description:

Hi,

Currently, we are receiving a warning "Database Cache Hit Ratio
(%)(Warning)" from one of the monitoring tools.

We use Postgres database for Jira, confluence, and bitbucket application and
hosted on a different machine and only 35% disc space is used.

Database warning “Database Cache Hit Ratio” issue has been fixed by
increasing the below values however after a few days of stability the
warning is back hence not sure increasing the below parameters are correct
or not.

shared_buffers = 2GB
effective_cache_size = 6GB
maintenance_work_mem = 512MB

Could you please suggest how much we can increase the parameters and how
does it impact the database. 

Thanks,
Rajiv Ranjan

On Tue, Mar 24, 2020 at 11:44:10AM -0400, Jeff Janes wrote:
>On Tue, Mar 24, 2020 at 8:06 AM PG Bug reporting form <
>noreply@postgresql.org> wrote:
>
>> The following bug has been logged on the website:
>>
>> Bug reference:      16314
>> Logged by:          Rajiv Ranjan
>> Email address:      rajiv.mca08@gmail.com
>> PostgreSQL version: 9.6.0
>> Operating system:   Red Hat Enterprise Linux Server release 7.6 (Maip)
>> Description:
>>
>> Hi,
>>
>> Currently, we are receiving a warning "Database Cache Hit Ratio
>> (%)(Warning)" from one of the monitoring tools.
>>
>
>This is not a bug in PostgreSQL.  It is arguably a bug in your unnamed
>monitoring tool.
>

Yeah, not a PostgreSQL bug.

>It is a dumb warning. The disk is there to be read from--doing so is not
>inherently a problem. Ignore the warning or disable it.
>

I wouldn't say it's entirely dumb, improving cache hit ratio may make 
huge difference, but it requires a lot more information than was
provided.

Rajiv, please send your question to pgsql-general or pgsql-performance
list, and be sure to include information about the system (amount of RAM
for example), resource utilization, workload, threshold currently used
by the alert, actual cache hit ratio, etc.

>Are the queries you care about too slow because data is occasionally read
>from disk?
>

Yeah, it makes little sense to deal with this unless you can demonstrate
some practical impact. In my experience low cache hit ratio values are
an issue with write-intensive workloads, in which case it may cause
significant write amplification.


regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Thu, Mar 26, 2020 at 07:21:42PM +0530, Rajiv Ranjan wrote:
>Hi Tomas,
>
>I can't find pgsql-general or pgsql-performance where I post my query hence
>posting all details here.
>

See the mailing lists at https://www.postgresql.org/list/

I'm not going to comment here, because this clearly is not a bug.


regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Fri, Mar 27, 2020 at 12:19:02PM +0530, Rajiv Ranjan wrote:
>I saw this but how could I submit my case
>https://www.postgresql.org/list/pgsql-general/
>

You need to subscribe to the mailing list, the instructions are here:

   https://www.postgresql.org/list/

and the URL for managing subscriptions is here:

   https://lists.postgresql.org/

You already have the community account I believe (you had to create one
before submitting the bug).

FWIW it's customary here not to top post, because it makes it harder to
follow the discussion. Please respond in-line in the future.


regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services