On Wed, Jul 30, 2014 at 1:05 PM, Kevin Grittner <kgrittn@ymail.com> wrote:
> Merlin Moncure <mmoncure@gmail.com> wrote:
>> On Wed, Jul 30, 2014 at 12:51 PM, Kevin Goess <kgoess@bepress.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.
In fact, looking at the png he attached, I'd bet they cranked up
work_mem and / or connections sometime around the end of January and
that's what we're seeing here. More memory used for sorts etc, less
left for caching.
--
To understand recursion, one must first understand recursion.
