From: | Greg Smith <gsmith(at)gregsmith(dot)com> |
---|---|
To: | Anton Melser <melser(dot)anton(at)gmail(dot)com> |
Cc: | Postgres General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: shared_buffers and shmmax what are the max recommended values? |
Date: | 2008-03-07 14:18:55 |
Message-ID: | Pine.GSO.4.64.0803070905300.29852@westnet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On Fri, 7 Mar 2008, Anton Melser wrote:
> We have a web app that is using a 32 bit 8.1.4 (I know but upgrading
> is not an option for another couple of months...)
You do know that upgrading takes a second if you do it right? You might
want to avoid VACUUM FULL until you can upgrade to >=8.1.9.
> I did, however, realise that I don't (didn't?) understand what shmmax
> REALLY is.
It's just a limit on how much shared memory a process can allocate. The
database server will allocate what it wants regardless, and all SHMMAX can
do is cause that to fail and the server to crash (on startup). If your
primary thing running here is PostgreSQL, you might as well set it to the
maximum you can so it gets out of the way. A popular setting is 2GB:
kernel.shmmax=2147483648
With 6GB of RAM, after that you could merrily increase shared_buffers to
200000 or so and possibly increase performance. Just watch your
checkpoints--they'll have more activity as you increase the buffer size,
and from your description you've still got checkpoint_segments at the tiny
default size. You say this is a web app, those typically aren't write
heavy so you'll probably be OK.
--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Ribe | 2008-03-07 14:43:10 | Re: JOIN and difference between timestamps |
Previous Message | Tom Lane | 2008-03-07 13:20:44 | Re: Violation of non existing reference |
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2008-03-07 14:22:16 | Commitfest status |
Previous Message | Tom Lane | 2008-03-07 13:07:24 | Re: 8.3.0 Core with concurrent vacuum fulls |