RE: I/O tuning... Allocating spindles to databases
- From: "Murching, Bob" <bob_murching@xxxxxxxxx>
- To: "'Kevin Closson'" <kevinc@xxxxxxxxxxxxx>, "'Mercadante, Thomas F (LABOR)'" <Thomas.Mercadante@xxxxxxxxxxxxxxxxx>, "'jkstill@xxxxxxxxx'" <jkstill@xxxxxxxxx>, "'cmarquez@xxxxxxxxxxxxxxxx'" <cmarquez@xxxxxxxxxxxxxxxx>
- Date: Thu, 15 Sep 2005 17:07:14 -0400
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.
>>>>>>--
>>>>>>//www.freelists.org/webpage/oracle-l
>>>>>>
>>>--
>>>//www.freelists.org/webpage/oracle-l
>>>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
