On Wed, Jul 30, 2014 at 1:05 PM, Kevin Grittner <kgri...@ymail.com> wrote: > Merlin Moncure <mmonc...@gmail.com> wrote: >> On Wed, Jul 30, 2014 at 12:51 PM, Kevin Goess <kgo...@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. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
