Thanks you for your response. Database config: shared_buffers = 8GB temp_buffers = 32MB work_mem = 64MB maintenance_work_mem = 512MB effective_cache_size = 16GB
In usual load there are not much pressure on memory, but it is possible to have all clients start using heavy reports. They are valid requests and could consume all memory. In this border and not likely but possible scenario it could be useful to let OOM killer to kill client's processes/connections but leave PostgreSQL system processes (postmaster, writer, stat, log, streaming, ...) excluded from reach of OOM killer. On Wed, Aug 1, 2012 at 11:48 AM, Kevin Grittner <kevin.gritt...@wicourts.gov > wrote: > Radovan Jablonovsky <radovan.jablonov...@replicon.com> wrote: > > > We are running PostgreSQL version 9.1.1 > > You should apply the latest bug fixes by updating to 9.1.4. > > http://www.postgresql.org/support/versioning/ > > > with 32GB of RAM, 32GB of SWAP and during high load we could reach > > (swap + RAM) memory limit. > > If you're even *starting* to swap you're doing something wrong, much > less exhausting swap space equal to actual RAM. What is your > configuration? > > http://wiki.postgresql.org/wiki/Server_Configuration > > While it's probably a good idea to configure the OOM killer to > behave more sanely, we tend to ignore it in favor of ensuring that > it never comes into play. We run about 200 databases 24/7 and I > think I've seen it kick in about twice -- when we ran queries that > leaked memory on each row in a big query. > > -Kevin > Radovan
