Infact the cache hit ratio that Oracle suggests is the minimum good
value is 95%. Anything below that is bad news. The reason is pretty
obvious - RAM transfer speed is around 3.2G/sec these days, whilst
even the best array isn't going to give more than 400MB/sec, and
that's not even starting to talk about seek time. anything below 90%
is not going to keep even the best disc hardware saturated. I know
that our dataset is 99% cached, and therefore better CPUs/better RAM
has a huge impact on overall performance.
Alex Turner
NetEconomist
On 11 Jan 2005 10:39:01 -0500, Greg Stark <[EMAIL PROTECTED]> wrote:
>
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
>
> > heh, our apps do tend to be CPU bound. Generally, I think the extra CPU
> > horsepower is worth the investment until you get to the really high end
> > cpus.
>
> I find that while most applications I work with shouldn't be cpu intensive
> they do seem end up being cpu bound quite frequently. What happens is that 90%
> of the workload has a working set that fits in RAM. So the system ends up
> being bound by the memory bus speed. That appears exactly the same as
> cpu-bound, though I'm unclear whether increasing the cpu clock will help.
>
> It's quite possible to have this situation at the same time as other queries
> are i/o bound. It's quite common to have 95% of your workload be frequently
> executed fast queries on commonly accessed data and 5% be bigger data
> warehouse style queries that need to do large sequential reads.
>
> Incidentally, the same was true for Oracle on Solaris. If we found excessive
> cpu use typically meant some frequently executed query was using a sequential
> scan on a small table. Small enough to fit in RAM but large enough to consume
> lots of cycles reading it.
>
> --
> greg
>
>
---------------------------(end of broadcast)---------------------------
TIP 3: 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
