Skip site navigation (1) Skip section navigation (2)

Re: how big shmmax is good for Postgres...

From: "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>
To: "Jessica Richard" <rjessil(at)yahoo(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: how big shmmax is good for Postgres...
Date: 2008-07-10 11:23:12
Message-ID: dcc563d10807100423m232f5d0aq44e736c98da1db6e@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Thu, Jul 10, 2008 at 4:53 AM, Jessica Richard <rjessil(at)yahoo(dot)com> wrote:
> On a Linux system,  if the total memory is 4G and the shmmax is set to 4G, I
> know it is bad, but how bad can it be? Just trying to understand the impact
> the "shmmax" parameter can have  on Postgres  and the entire system after
> Postgres comes up on this number.

There are two settings, shmmax for the OS, and shared_buffers for
pgsql.  If the OS has a max setting of 4G but pgsql is set to use
512Meg then you'd be safe.

Now, assuming that both the OS and pgsql are set to 4G, and you're
approaching that level of usage, the OS will start swapping out to
make room for the shared memory.  The machine will likely be starved
of memory, and will go into what's often called a swap storm where it
spends all its time swapping stuff in and out and doing little else.

> What is the reasonable setting for shmmax on a 4G total machine?

Keep in mind that postgresql's shared buffers are just one level of
caching / buffering that's going on.  The OS caches file access, and
sometimes the RAID controller and / or hard drive.

Generally the nominal setting is 25% of memory, but that's variable.
If the working set of your data will fit in 10% then there's no need
for setting shared_memory to 25%...

In response to

Responses

pgsql-performance by date

Next:From: Scott MarloweDate: 2008-07-10 12:11:47
Subject: Re: how big shmmax is good for Postgres...
Previous:From: Bill MoranDate: 2008-07-10 11:19:19
Subject: Re: how big shmmax is good for Postgres...

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group