From: | Kevin Goess <kgoess(at)bepress(dot)com> |
---|---|
To: | Shaun Thomas <sthomas(at)optionshouse(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-09-04 18:08:28 |
Message-ID: | CABZkbxjEDd4ABNGk-Ymzu8_40LA+yH116jxPZ3ckoa-rCQEPiQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
This is a super-interesting topic, thanks for all the info.
On Thu, Sep 4, 2014 at 7:44 AM, Shaun Thomas <sthomas(at)optionshouse(dot)com>
wrote:
>
> Check /proc/meminfo for a better breakdown of how the memory is being
> used. This should work:
>
> grep -A1 Active /proc/meminfo
>
> I suspect your inactive file cache is larger than the active set,
> suggesting an overly aggressive memory manager.
$ grep -A1 Active /proc/meminfo
Active: 34393512 kB
Inactive: 20765832 kB
Active(anon): 13761028 kB
Inactive(anon): 890688 kB
Active(file): 20632484 kB
Inactive(file): 19875144 kB
The inactive set isn't larger than the active set, they're about even, but
I'm still reading that as the memory manager being aggressive in marking
pages as inactive, is that what it says to you too?
Interestingly, I just looked at the memory graph for our standby backup
database, and while it *normally* uses all the available RAM as the page
cache, which is what I'd expect to see, when it was the active database for
a time in April and May, the page cache size was reduced by about the same
margin. So it's the act of running an active postgres instance that causes
the phenomenon.
http://s76.photobucket.com/user/kgoesspb/media/db2-mem-historic.png.html
--
Kevin M. Goess
Software Engineer
Berkeley Electronic Press
kgoess(at)bepress(dot)com
510-665-1200 x179
www.bepress.com
bepress: sustainable scholarly publishing
From | Date | Subject | |
---|---|---|---|
Next Message | Nelson Green | 2014-09-04 19:44:50 | Re: Employee modeling question |
Previous Message | Eric Fleming | 2014-09-04 15:17:40 | Re: GiST index question |