Re: Memory Performance?

Hi,
 lets assume, i/o accounts for 95% of the time.  if you put all your data in memory, the most improvement you can get  is 95%, e.g. 20 fold performance, not 1000.

Karsten

In article <38D1B6B4.47A54A8A_at_pluto.njcc.com>, "Jerry D. Harris Jr." <harrisjd_at_pluto.njcc.com> wrote:
> Peter,
>
> Thomas, who's Thomas? I'm Jerry! :)
>
> Sorry if I was a little too vague... Basically I meant running the
 same
> test twice so that the KEEP pool is primed. It just that I am not
 floored
> by the differences in speed, I can verify it is coming from the keep
 pool
> and not the disks.
>
> So my burning question still is what's throttling it back?
>
> -Jerry
>
> Peter wrote:
>
> > Thomas,
> >
> > Well, remember that the keep buffer has to be loaded. So the
> > first query is probably still pulling data from the tablespace.
> > However, queries after that should be pulling data from the keep
> > buffer.
> >
> > Also, make sure that your keep buffer is big enough for all the
> > data you're trying to load.
> >
> > We did a search engine application for one of our web site clients
> > and we added a procedure to the database startup scripts that
> > primed the keep buffer cache to get things pre-loaded prior
> > to actual hits by the users. We load the huge keep buffer with
> > not only table data but also indexes as well. Performance, is
> > pretty darn good. But, i would encourage you to check your queries
> > with the sql*plus autotrace option taking advantage of the various
> > hints will do. Sometimes you think one sql/hint combo method should
> > be faster but with a little playing...you find unexpected combo
 gives
> > better performance.
> >
> > Anyway... that's my 2 cents.
> >
> > Good luck,
> > Allen
> > http://hayden.home.mindspring.com
> >
> > harrisjd_at_pluto.njcc.com wrote in message
> > <38d07c5d.4174263_at_129.250.35.141>...
> > >A have a question, something that has been bugging me for some time
> > >across all platforms....
> > >
> > >Generally speaking, let's suppose....
> > >
> > >1. you have a SQL statement that performs a full table scan
> > >2. you run it once, it comes back in say 60 seconds.
> > >3. you run it again, and lets say it comes back in 30 seconds, a
 200%
> > >improvement.
> > >4. Ok, now you decide to implement a KEEP pool large enough to hold
> > >the entire table.
> > >5. Shutdown and restart the instance/server/etc, run the same
> > >statement again.
> > >
> > >The timings are identical.
> > >
> > >Therefor, I am forcing the table to be in RAM. I can verify it with
> > >consistent gets. I am on a local wire, so the network performance
> > >is not an issue. I am on a quiet box, so the box is not loaded. RAM
> > >is ok on the box.
> > >
> > >If RAM is supposed to be at least 1000x faster than DISK (not
 adding
> > >in rotational delay, etc.), why don't I get at least 1000x the
> > >performance???
> > >
> > >Let me also say that from my experience, I have also seen this
> > >disparity. I have several production systems utilizing multiple
> > >buffer pools, and every other conceivable performance parameter in
> > >them with 99.9% hit ratios and the performance isn't that different
> > >from when the instance first starts or after a week after it has
 been
> > >running.
> > >
> > >This has plagued me since DBASE 3+ for a PC. For example, I setup a
> > >virtual drive large enough to hold the databases, indexes and
> > >application code, and again performance never knocked my socks off.
> > >
> > >Any insight as to why this is so?
> > >
> > >
> > >-Jerry
> > >
> > >P.S. Can you please reply to my email in addition to the newsgroup?
> > >I do not check the news groups regularly.
>
>

Sent via Deja.com http://www.deja.com/
Before you buy. Received on Fri Mar 17 2000 - 00:00:00 CST