On Mon, 2004-12-27 at 22:31 +0700, Amrit Angsusingh wrote:
> [ iain@mst.co.jp ]
> >
> > These are some settings that I am planning to start with for a 4GB RAM
> > dual
> > opteron system with a maximum of 100 connections:
> >
> >
> > shared_buffers 8192 (=67MB RAM)
> > sort_mem 4096 (=400MB RAM for 100 connections)
> > effective_cache_size 380000(@8KB =3.04GB RAM)
> > vacuum_mem 32768 KB
> > wal_buffers 64
> > checkpoint_segments 8
> >
> > In theory, effective cache size is the amount of memory left over for the
> > OS
> > to cache the filesystem after running all programs and having 100 users
> > connected, plus a little slack.
> I reduced the connection to 160 and configured as below there is some
> improvement in speed .
> shared_buffers = 27853 [Should I reduce it to nearly as you do and what
> will happen?]
at some point, more shared buffers will do less good than leaving the
memory to the OS to use as disk buffers. you might want to experiment
a bit with different values to find what suits your real-life conditions
> sort_mem = 8192
> vacuum_mem = 16384
> effective_cache_size = 81920 [Should I increase it to more than 200000 ?]
as Iain wrote, this value is an indication of how much memory will be
available to the OS for disk cache.
when all other settings have been made, try to see how much memory your
OS has left under normal conditions, and adjust your setting
accordingly, if it differs significantly.
I have seen cases where an incorrect value (too low) influenced the
planner to use sequential scans instead of better indexscans,
presumably because of a higher ratio of estimated cache hits.
> Thanks for any comment again.
>
> NB. There is a huge diaster in my country "Tsunamies" and all the people
> over the country include me felt into deep sorrow.
my condolescences.
> Amrit Angsusingh
> Thailand
gnari