On Aug 28, 2007, at 4:33 PM, Marko Kreen wrote:
On 8/24/07, Jeff Amiel <becauseimjeff@xxxxxxxxx> wrote:
Over last 2 days, have spotted 10 "Out of Memory"
errors in postgres logs (never saw before with same
app/usage patterns on tuned hardware/postgres under
FreeBSD)
Aug 22 18:08:24 db-1 postgres[16452]: [ID 748848
local0.warning] [6-1] 2007-08-22 18:08:24 CDT ERROR:
out of memory.
Aug 22 18:08:24 db-1 postgres[16452]: [ID 748848
local0.warning] [6-2] 2007-08-22 18:08:24 CDT
DETAIL: Failed on request of size 536870910.
What I found interesting is that It's ALWAYS the same
size....536870910
I am running autovacuum and slony.....but I see
nothing in the logs anywhere near the "out of memory"
errors related to either (autovacuum used to under
8.0.X log INFO messages every time it vacuumed which
came in handy...I assume it doesn't so this any more?)
The events are fairly spread out...and cannot (by
looking at app logs and rest of DB logs) correlate to
any specific query or activity.
Any help would be appreciated
I've experienced something similar. The reason turned out to be
combination of overcommit=off, big maint_mem and several parallel
vacuums for fast-changing tables. Seems like VACUUM allocates
full maint_mem before start, whatever the actual size of the table.
Fix was to put "set maint_mem=32M" before small vacuums and
serialize some of them.
I'm not sure about the OP but I know that we just run autovacuum so
no problem with parallel vacuums. In addition, Solaris doesn't have
overcommit.
Erik Jones
Software Developer | Emma®
erik@xxxxxxxxxx
800.595.4401 or 615.292.5888
615.292.0777 (fax)
Emma helps organizations everywhere communicate & market in style.
Visit us online at http://www.myemma.com
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
