Re: How can we avoid reclustering some indexes ??

> By the way, I belive, Informix recommended 20-25% of RAM for BUFFERS is > conservative and ignores client-server reality in which most of us live > now (no users' applications on the database box). I came to 60% (but be > aware of swapping!) It depends on what kind of environment you're running. In a pure OLTP setup, you'd want to maximize your buffers. However, in a DSS system, you want to maximize your virtual memory, which is where the 20-25% recommendation for buffers comes from. For OLTP, you probably want 75% or so going to buffers. Most environments lie somewhere in between, though...

Chuck Renaud wrote: > > > By the way, I believe, Informix recommended 20-25% of RAM for BUFFERS is > > conservative and ignores client-server reality in which most of us live > > now (no users' applications on the database box). I came to 60% (but be > > aware of swapping!) > > It depends on what kind of environment you're running. In a pure > OLTP setup, you'd want to maximize your buffers. However, in a > DSS system, you want to maximize your virtual memory, which is > where the 20-25% recommendation for buffers comes from. For > OLTP, you probably want 75% or so going to buffers. Most > environments lie somewhere in between, though... Sorry for misunderstanding, I don't give 60% as general recommendation. Recommendation is to start from 20% and tune up keeping eye on free memory cushion, onstat -g seg, swapping, etc. 60% is where I stopped for particular system I just tuned (7.24, 512M RAM, Fourth Generation Accounting). %cached reads came from 90-91 to 99+, and (talking of DDS) reports which took couple hours run for 15 min. The point is - if somebody is buying 1 Gb of extra RAM to rev up performance, not 200 M should be added to BUFFERS, but much more, maybe almost everything.