Re: oom_killer

From: Tory M Blue <tmblue(at)gmail(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: oom_killer
Date: 2011-04-24 04:22:22
Message-ID: BANLkTikru03-XHoX2vW6aY9KkKGhVG42=g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Sat, Apr 23, 2011 at 12:24 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> One thing to watch is the size of the filesystem cache. Generally as the system comes under memory pressure you will see the cache shrink. Not sure what is happening on your system, but typically when it gets down to some minimal size, that's when 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

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Stefan Keller 2011-04-24 09:38:53 Re: How to configure a read-only database server?
Previous Message Robert Haas 2011-04-23 19:44:23 Re: REINDEX takes half a day (and still not complete!)