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 [EMAIL PROTECTED] Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
