Re: tuning questions

On Thu, 2003-12-04 at 12:27, Richard Huxton wrote:
> On Thursday 04 December 2003 19:50, Jack Coates wrote:
> >
> > I'm trying to set Postgres's shared memory usage in a fashion that
> > allows it to return requested results quickly. Unfortunately, none of
> > these changes allow PG to use more than a little under 300M RAM.
> > vacuumdb --analyze is now taking an inordinate amount of time as well
> > (40 minutes and counting), so that change needs to be rolled back.
>
> You don't want PG to use all your RAM, it's designed to let the underlying OS
> do a lot of caching for it. Probably worth having a look at vmstat/iostat and
> see if it's saturating on I/O.

latest changes:
shared_buffers = 35642
max_fsm_relations = 1000
max_fsm_pages = 10000
wal_buffers = 64
sort_mem = 32768
vacuum_mem = 32768
effective_cache_size = 10000

/proc/sys/kernel/shmmax = 500000000

IO is active, but hardly saturated. CPU load is hefty though, load
average is at 4 now.

   procs                      memory    swap          io
system         cpu
 r  b  w   swpd   free   buff  cache  si  so    bi    bo   in    cs  us
sy  id
 0  2  1   2808  11436  39616 1902988   0   0   240   896  765   469
2  11  87
 0  2  1   2808  11432  39616 1902988   0   0   244   848  768   540
4   3  93
 0  2  1   2808  11432  39616 1902984   0   0   204   876  788   507
3   4  93
 0  2  1   2808  11432  39616 1902984   0   0   360   416  715   495
4   1  96
 0  2  1   2808  11432  39616 1902984   0   0   376   328  689   441
2   1  97
 0  2  0   2808  11428  39616 1902976   0   0   464   360  705   479
2   1  97
 0  2  1   2808  11428  39616 1902976   0   0   432   380  718   547
3   1  97
 0  2  1   2808  11428  39616 1902972   0   0   440   372  742   512
1   3  96
 0  2  1   2808  11428  39616 1902972   0   0   416   364  711   504
3   1  96
 0  2  1   2808  11424  39616 1902972   0   0   456   492  743   592
2   1  97
 0  2  1   2808  11424  39616 1902972   0   0   440   352  707   494
2   1  97
 0  2  1   2808  11424  39616 1902972   0   0   456   360  709   494
2   2  97
 0  2  1   2808  11436  39616 1902968   0   0   536   516  807   708
3   2  94

--
Jack Coates, Lyris Technologies Applications Engineer
510-549-4350 x148, jack@lyris.com
"Interoperability is the keyword, uniformity is a dead end."
                --Olivier Fourdan