From: | Shaun Thomas <sthomas(at)optionshouse(dot)com> |
---|---|
To: | Kevin Goess <kgoess(at)bepress(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: free RAM not being used for page cache |
Date: | 2014-08-05 15:27:17 |
Message-ID: | 53E0F7D5.5010502@optionshouse.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 07/30/2014 12:51 PM, Kevin Goess 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.
What version of the Linux kernel are you using? We had exactly this
problem when we were on 3.2. We've since moved to 3.8 and that solved
this issue, along with a few others.
If you're having the same problem, this is not a NUMA issue or in any
way related to zone_reclaim_mode. The memory page aging algorithm in pre
3.7 is simply broken, judging by the traffic on the Linux Kernel Mailing
List (LKML).
I hate to keep beating this drum, but anyone using 3.2 (default for a
few Linux distributions) needs to stop using 3.2; it's hideously broken.
--
Shaun Thomas
OptionsHouse, LLC | 141 W. Jackson Blvd. | Suite 800 | Chicago IL, 60604
312-676-8870
sthomas(at)optionshouse(dot)com
______________________________________________
See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email
From | Date | Subject | |
---|---|---|---|
Next Message | john gale | 2014-08-05 19:16:45 | understanding why two nearly identical queries take two different planner routes, one 5s and one 2hr |
Previous Message | Shaun Thomas | 2014-08-05 15:05:55 | Re: Reindex taking forever, and 99% CPU |