From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Matt Magoffin <postgresql(dot)org(at)msqr(dot)us>, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Out of memory on SELECT in 8.3.5 |
Date: | 2009-02-09 21:43:39 |
Message-ID: | 24187.1234215819@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Matt Magoffin (postgresql(dot)org(at)msqr(dot)us) wrote:
>> Yes... and indeed changing vm.overcommit_ratio to 80 does allow that
>> previously-failing query to execute successfully. Do you think this is
>> also what caused the out-of-memory error we saw today just when a
>> transaction was initiated?
> Almost certainly.. You were running close to the edge *system-wide* on
> memory allocations based on your meminfo results. You'll want to keep
> an eye on the limit vs. the committed amount going forward so as to
> avoid this happening in the future. It's just about the same as
> watching how you're doing on overall memory usage in the box or on swap
> usage. Set up some nagios monitoring, and alarm once
> Committed_As/CommitLimit goes over 90%.
IIRC, our documentation points out vm.overcommit_memory as a critical
parameter, but says nothing about overcommit_ratio nor how to find out
how close you are to hitting that limit. Without necessarily being
prescriptive about the best strategy, should we add some info to let
people know about these things? This thread was mostly news to me,
so I suspect it's news to some other folk as well.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | SHARMILA JOTHIRAJAH | 2009-02-09 21:46:34 | ora2pg or dbi_link ? |
Previous Message | Matt Magoffin | 2009-02-09 21:40:12 | Re: Out of memory on SELECT in 8.3.5 |