RE: Orion, NetApp, and iops

  • From: "Crisler, Jon" <Jon.Crisler@xxxxxxx>
  • To: <henry@xxxxxxxxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
  • Date: Mon, 3 May 2010 14:20:33 -0400

Two things come to mind-  first is caching on the Netapp side, and
second - there is some Oracle-accelerator thingy available on Netapp
that might be affecting your results.
Your calculated physical numbers to me look low- but your actual numbers
reported seem to fit with what I have seen published / reported on
Netapp hardware.
You did not mention which NetApp model you have....

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Henry Poras
Sent: Monday, May 03, 2010 12:25 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: Orion, NetApp, and iops

I was taking some preliminary Orion runs on a new system just handed off

to us. Orion ran and all the lineshapes looked about right (iops 
increased linearly with load until saturation) and really pretty, but 
there is some stuff I can't explain.

I was running against one LUN (made up of 3 aggregates) comprised of 48 
disks (15K). Each disk can provide ~180 iops so I was expecting 
saturation at ~8640 iops.

orion -write 0 -num_disks 100 -duration 120 -num_large 0 (100% read, all

8K reads, -num_disks is high enough to crank the load, increase duration

to allow enough aio calls in flight)

So for 8K reads and 100% reads I got my iops to saturate at ~67,000 
(instead of the expected 8640).

-Was it a bug in Orion?   I looked at iostat and it was consistent with 
Orion.
-Was it read cache on the NetApp? Maybe, but I saturated at a load of 
~35-50 which is consistent with my number of disks. This implies to me 
that I am actually hitting the disks.
-Could it be some funny read ahead algorithm?  Maybe Orion thinks it is 
doing 8 i/o calls, but the NetApp is doing some read ahead so only one 
call is an actual PIO and the rest are from cache. How can I test this? 
Is this an anomaly of the experiment? How could I disable this to get a 
better feel for production (or maybe this would still happen in
production?)
-Any other thoughts?

I don't like numbers without a model within which to understand them and

storage is a bit of a black box to me.

Thanks.

Henry
--
//www.freelists.org/webpage/oracle-l


--
//www.freelists.org/webpage/oracle-l


Other related posts: