On Tue, Mar 21, 2006 at 02:03:19PM +0100, Guillaume Cottenceau wrote:
> "Jim C. Nasby" <jnasby 'at' pervasive.com> writes:
>
> > On Tue, Mar 21, 2006 at 10:40:45PM +1200, Mark Kirkwood wrote:
> > > I was going to recommend higher - but not knowing what else was running,
> > > kept it to quite conservative :-)... and given he's running java, the
> > > JVM could easily eat 512M all by itself!
> >
> > Oh, didn't pick up on java being in the mix. Yeah, it can be a real pig.
> > I think people often place too much emphasis on having a seperate
> > application server, but in the case of java you often have no choice.
>
> Fortunately the servers use 2G or 4G of memory, only my test
> machine had 1G, as I believe I precised in a message; so I'm
> definitely going to use Mark's advices to enlarge a lot the
> shared buffers. Btw, what about sort_mem? I have seen it only
> little referenced in the documentation.
The biggest issue with setting work_mem (you're not doing current
development on 7.4 are you?) is ensuring that you don't push the server
into swapping. Remember that work_mem controls how much memory can be
used for EACH sort or hash (maybe others) operation. Each query can
consume multiples of work_mem (since it can do multiple sorts, for
example), and of course each backend could be running a query at the
same time. Because of all this it's pretty difficult to make work_mem
recomendations without knowing a lot more about your environment.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
