From: | "Steve Wolfe" <steve(at)iboats(dot)com> |
---|---|
To: | "Pgsql-General \(E-mail\)" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Performance tuning for linux, 1GB RAM, dual CPU? |
Date: | 2001-07-11 17:47:44 |
Message-ID: | 000f01c10a31$9d1419a0$50824e40@iboats.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> Christian Bucanac <christian(dot)bucanac(at)mindark(dot)com> writes:
> >> I am going to try 768M (98304) for buffers and 6144 (6144 * 32 =
192M)
> >> for sort mem. This way with the DB server serving a max of 32
application
> >> servers the kernel and other processes should still have the last
64Mb RAM.
>
> This is almost certainly a lousy idea. You do *not* want to chew up all
> available memory for PG shared buffers; you should leave a good deal of
> space for kernel-level disk buffers.
I'll second that. The way that I tuned our installation was:
1. Make sure you have enough RAM that the data files are *always* in
cache, and that all apps have enough RAM available for them.
2. Increase shared buffers until there was no performance increase, then
double it.
3. Increase sort memory until there was no performance increase, then
double it.
4. Turn off fsync().
5. Make sure that #1 still applies.
In our system (1.5 gigs), that ended up being 128 megs of shared
buffers, and 64 megs for sorting. Some day, I'll probably increase the
shared buffers more (just because I can), but currently, Linux doesn't
seem to let me set SHMMAX over 128 megs. Some day I'll look into it. : )
steve
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Choe | 2001-07-11 17:48:01 | changing partial data |
Previous Message | Steve Wolfe | 2001-07-11 17:36:32 | Idle postmasters.... |