RE: I/O tuning... Allocating spindles to databases
- From: "Murching, Bob" <bob_murching@xxxxxxxxx>
- To: "'kevinc@xxxxxxxxxxxxx'" <kevinc@xxxxxxxxxxxxx>, "'oracle-l@xxxxxxxxxxxxx'" <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 15 Sep 2005 18:25:38 -0400
In retrospect, you're right, I could see how the presence of cache could
degrade performance (a little). Are there any arrays that are capable of
streaming data from disk to both the host (via fiber/fcal/scsi/gbe/whatever)
and cache *simultaneously* ? Or, when a physical read occurs that must be
cached, is the data first placed in the onboard cache, *then* read from
cache and sent on its way to the host as probably is the case with most
arrays? I'd imagine this is the case with, say, a Symmetrix-type array
which I believe has processors doing the dirty work on both sides of the
cache. It takes a lot of of spindles before memory-to-memory throughput
starts to become a bottleneck on an "intelligent" SAN but I can see how a
couple of percentage points could get consumed. Moreover big SAN/NAS boxes
have their own processors, operating systems, patches, crashes and
performance issues that could add additional latency to a given IOP.
I miss the days when, in the event of throughput issues, you only needed to
check into the size of the pipe and utilization of the disk spindles. Now
you have to deal with storage backplane bandwidth, protocol overhead, CPU
load, SAN/NAS OS efficiency, and so forth. In the push to up utilization
efficiency (of any kind of hardware) through virtualization, the notion of
guaranteed performance has been tossed out the window. Now you have 100
systems running virtualized on one server connected to one SAN that presents
100 virtualized disks, and heaven help you if something is slow! At least
our end-user's desktop PCs aren't being too virtualized... oh wait, we got
Citrix too....
-----Original Message-----
From: Kevin Closson [mailto:kevinc@xxxxxxxxxxxxx]
Sent: Thursday, September 15, 2005 5:45 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: 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.
I've done a lot of benchmarking on systems configured with over 1000 disk
drives and believe me, caching data that will never be revisted does not
boost performance.
Think FTS. I have used arrays that allow you to completely disable cache and
doing so on the tables that sustain scans was often a performance boost.
Mileage varies.
>>>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
That is because it is a single headed NAS. You need to see HP's story with
the Enterprise File Server Clustered Gateway. Supports 16 active:active
heads with no SPOF.
ftp://ftp.compaq.com/pub/products/storageworks/efs/4AA0-0283ENW.pdf
Besides, it's OEMed PolyServe :-)
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
