Re: free RAM not being used for page cache
От | Scott Marlowe |
---|---|
Тема | Re: free RAM not being used for page cache |
Дата | |
Msg-id | CAOR=d=1n3WXghg_hjojk3JAQN-1SE5xj+KOtv4v9GcJ0wQKv5w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: free RAM not being used for page cache (Kevin Grittner <kgrittn@ymail.com>) |
Список | pgsql-general |
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.
В списке pgsql-general по дате отправления: