RE: Time to read 6000 (block size 2k) blocks

  • From: "Mark W. Farnham" <mwf@xxxxxxxx>
  • To: <oracle-l@xxxxxxxxxxxxx>
  • Date: Fri, 6 Aug 2004 10:49:16 -0400

One of our calculators is broke.

I get 21.86/6126 = .003568

Move the decimal point and it is 3.57 ms.

Let's see, rounded number sanity check: 22*1000/6000 is about 22/6, so yeah,
3.6 ms is about right.

I don't think youse need more iron, but *probably* a move to 8K or 16K
blocksize will help you.

Unless a few things:

If you still end up reading the same number of blocks because the rows are
scattered with respect to the rows you need.
If you get hot blocks on the insertion side so bad it doesn't matter how
fast you can read later.
If the increased block size tips you over on memory usage so that you're
cacheing so much less that you have to do real physical reads frequently
where now you're mostly reading from cache.

Personally I've never had joy on large systems with 2K blocks, and with
direct i/o the net-net has always worked out better at 16K than 8K, but I'm
sure my view of the world is skewed from trying to fit things like GL OPEN
PERIOD and PA LABOR ALLOCATION into a given window more than trying to
handle tens of thousands of users. I've also never tried to use 16K where
that was a mismatch with the i/o chain, such as on an 8K blocksize
filesystem.

Now if it was 46 ms, I'd be looking for a way to either cache more or
straighten out something in the i/o chain as
per Jurijs.

mwf

PS: of course if you really don't need to be reading all those blocks,
improved sql is less disruptive to implement

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of J.Velikanovs@xxxxxxxx
Sent: Friday, August 06, 2004 10:09 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: Time to read 6000 (block size 2k) blocks


(21.86/6126)*1000 = 45,7ms/pio.
By my experience everything what is below 20ms in general is OK.
High end need to be quicker ~10ms.
We have HP EVA solution implemented.
The response time is 5 ms, even in high load situations (There 12 CPU, RAC
configuration).
.
In your case 45 ms can be the problem.
I would discuss this with system administrators or supplier
representatives.
.
PS Do not forget about throughput of channels 180Mbit/s, 320Mbit/s,
1Gbit/s. Check sum of IO stream volumes.

Jurijs
+371 9268222 (+2 GMT)
============================================
Thank you for teaching me.
http://otn.oracle.com/ocm/jvelikanovs.html






jaysingh1@xxxxxxxxxxxxx
Sent by: oracle-l-bounce@xxxxxxxxxxxxx
06.08.2004 16:48
Please respond to oracle-l

        To:     oracle-l@xxxxxxxxxxxxx
        cc:
        Subject:        Time to read 6000 (block size 2k) blocks


Hi All,

The question may be wispy.
We have 14 CPU sun box,8i 2 node OPS. Not under heavy load.

In our case it is taking 21.86 sec for 6126 blocks (from disk)

db file sequential read                      6126        0.29 21.86

Approximately how long it should take to read 6000 blocks?


call     count       cpu    elapsed       disk      query    current  rows
------- ------  -------- ---------- ---------- ---------- ----------
----------
Parse        1      0.01       0.01          0          0          0     0
Execute      1      0.00       0.00          0          0          0     0
Fetch        2     11.39      41.98       6126      18805          0     1
------- ------  -------- ---------- ---------- ---------- ----------
----------
total        4     11.40      41.99       6126      18805          0     1



db file sequential read                      6126        0.29 21.86

Thanks
Sami


----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------



----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------


----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Other related posts: