RE: I/O tuning... Allocating spindles to databases

Even if such access patterns are less than likely, it's still important to
know how storage responds in worst case scenarios.  Cache on the SAN/NAS is
not a bad thing.  I can't think of a situation where it would *degrade*
performance merely by its presence.  However, cache can mask architectural
problems with the storage subsystem that cause real-world performance
problems, therefore you have to evaluate uncached throughput *in addition
to* cached throughput when comparing different storage solutions.  

We've had a NetApp with rather fast disk and huge cache.  Burst performance
indeed can be good.  But, the thing has effectively single gigabit fiber
backbone and a single and heavily burdened storage processor that renders it
incapable of sustaining more than maybe sixty (60) megabytes/sec sustained
I/O out of a chassis that holds some 90+ 10krpm fiber disks.  Cache does a
great job of hiding that problem... Until the moment a single report
overruns both Oracle's buffer cache as well as the NAS onboard cache.  In
seconds, performance is toast.



-----Original Message-----
From: Kevin Closson [mailto:kevinc@xxxxxxxxxxxxx] 
Sent: Thursday, September 15, 2005 3:37 PM
To: Mercadante, Thomas F (LABOR); jkstill@xxxxxxxxx;
cmarquez@xxxxxxxxxxxxxxxx
Cc: bob_murching@xxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Subject: RE: I/O tuning... Allocating spindles to databases

 
absolutely..it is VERY real life to have an access pattern that completely
obliterates cache...

I can't count how many shops I've known
that completely glue a high end EMC to
the wall and lament the fact that there
is no way to disable the cache...

that was on particular models, I don't
claim to be an EMC expert by any means.

>>>-----Original Message-----
>>>From: Mercadante, Thomas F (LABOR)
>>>[mailto:Thomas.Mercadante@xxxxxxxxxxxxxxxxx]
>>>Sent: Thursday, September 15, 2005 12:33 PM
>>>To: kevinc@xxxxxxxxxxxxx; jkstill@xxxxxxxxx; 
>>>cmarquez@xxxxxxxxxxxxxxxx
>>>Cc: bob_murching@xxxxxxxxx; oracle-l@xxxxxxxxxxxxx
>>>Subject: RE: I/O tuning... Allocating spindles to databases
>>>
>>>But would something like this ever really happen in real life.  We 
>>>can all make hardware/software fail once we know what its weaknesses 
>>>are.
>>>
>>>Hell, I can make a database server fail.  Quite simple really.  Walk 
>>>into the server room and flip the breaker.
>>>Shuts down every time!
>>>
>>>-----Original Message-----
>>>From: oracle-l-bounce@xxxxxxxxxxxxx
>>>[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Kevin Closson
>>>Sent: Thursday, September 15, 2005 3:26 PM
>>>To: jkstill@xxxxxxxxx; cmarquez@xxxxxxxxxxxxxxxx
>>>Cc: bob_murching@xxxxxxxxx; oracle-l@xxxxxxxxxxxxx
>>>Subject: RE: I/O tuning... Allocating spindles to databases
>>>
>>> >>>
>>>>>>It isn't too difficult to write a simulation that will render the 
>>>>>>cache useless.
>>>
>>>actually quite easy. create a file that is 100 fold larger than cache 
>>>and do completely random 4KB transfers.
>>>
>>>smoked
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>>>
>>>>>>
>>>>>>--
>>>>>>Jared Still
>>>>>>Certifiable Oracle DBA and Part Time Perl Evangelist
>>>>>>11+ years of trying to appear to know what I'm doing.
>>>>>>--
>>>>>>http://www.freelists.org/webpage/oracle-l
>>>>>>
>>>--
>>>http://www.freelists.org/webpage/oracle-l
>>>
--
http://www.freelists.org/webpage/oracle-l

Other related posts: