From: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com>, Kevin Goess <kgoess(at)bepress(dot)com> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: free RAM not being used for page cache |
Date: | 2014-07-30 19:05:18 |
Message-ID: | 1406747118.72113.YahooMailNeo@web122301.mail.ne1.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> On Wed, Jul 30, 2014 at 12:51 PM, Kevin Goess <kgoess(at)bepress(dot)com> wrote:
>
>> A couple months ago we upgraded the RAM on our database servers from 48GB to
>> 64GB. Immediately afterwards the new RAM was being used for page cache,
>> which is what we want, but that seems to have dropped off over time, and
>> there's currently actually like 12GB of totally unused RAM.
> could be a numa issue.
I was thinking the same thing.
The other thought was that it could be a usage pattern and/or
monitoring issue. When there are transient requests for large
amounts of memory, it will discard cache to satisfy those (e.g.,
work_mem or maintenance_work_mem allocations). If the *active*
portion of the database is not as big as RAM, it might not refill
right away. This could be compounded on your monitoring graphs if
they summarize by taking the *average* RAM usage for an interval
rather than the *maximum* usage for that interval. Intermittent
spikes in usage could make it look like the RAM is unused if you
are averaging; personally, I would prefer to use maximum for a
metric like this. Many monitoring systems allow you to choose.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2014-07-30 19:07:12 | Re: free RAM not being used for page cache |
Previous Message | Seref Arikan | 2014-07-30 19:01:02 | Re: How can I create null value from function call with no results? |