Re: oom_killer - Mailing list pgsql-performance

From Tory M Blue
Subject Re: oom_killer
Date
Msg-id BANLkTikru03-XHoX2vW6aY9KkKGhVG42=g@mail.gmail.com
Whole thread Raw
In response to Re: oom_killer  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-performance
On Sat, Apr 23, 2011 at 12:24 PM, Robert Haas <robertmhaas@gmail.com> wrote:

> One thing to watch is the size of the filesystem cache. Generally as the system comes under memory pressure you will
seethe cache shrink. Not sure what is happening on your system, but typically when it gets down to some minimal size,
that'swhen the swapping starts. 
>
> ...Robert

Thanks everyone, I've tuned the system in the tune of overcommit 2 and
ratio of 80% this makes my commit look like:
CommitLimit:    31694880 kB
Committed_AS:    2372084 kB


So with 32G of system memory and 4gb cache so far it's running okay,
no ooms in the last 2 days and the DB is performing well again. I've
also dropped the shared buffers to 2gb, that gives me 1 gb for data
etc. I'll test with smaller 1.5gb if need be.

I've already started the 64bit process, I've got to test if slon will
replicate between a 32bit and 64 bit system, if the postgres/slon
versions are the same (slon being the key here). If this works, I will
be able to do the migration to 64bit that  much easier, if not well,
ya that changes the scheme a ton.

Thanks for the all the assistance in this, it's really appreciated

Tory

pgsql-performance by date:

Previous
From: Paul Pierce
Date:
Subject: Issue with partition elimination
Next
From: Stefan Keller
Date:
Subject: Re: How to configure a read-only database server?