> Christian Bucanac <christian.bucanac@mindark.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.
>
> Other fallacies in the above: (1) you're assuming the SortMem parameter
> applies once per backend, which is not the case (it's once per sort or
> hash step in a query, which could be many times per backend); (2) you're
> not allowing *anything* for any space usage other than shared disk
> buffers and sort memory.
>
> The rule of thumb I recommend is to use (at most) a quarter of real RAM
> for shared disk buffers. I don't have hard measurements to back that
> up, but I think it's a lot more reasonable as a starting point than
> three-quarters of RAM.
In my testing with *particluar* environment (Linux kernel 2.2.x,
pgbench), it was indicated that too many shared buffers reduced the
performance even though there was lots of memory, say 1GB. I'm not
sure why, but I suspect there is a siginificant overhead to lookup
shared buffers.
--
Tatsuo Ishii
