Btw, probably being a SAN guy at heart I’m truly impressed with HP’s EVA data layout. Gone are contiguous data stripes replaced with independent blocks that can be relocated by policy to satisfy load balancing / IO assignment needs. I think HP’s taken the next logical step in the high concurrency data layout of the Symm DMX . I haven’t been following DMX, so they might be moving in the same direction, albeit more slowly considering the scales and install base of DMX.

If you don’t mind emailing me I have an unrelated question I’d like to ask you offline. Thanks.

Coming from a sys admin background in platforms and SAN I have some experience tweaking performance on mid to high end arrays.

The most bang for the buck tweak, barring correcting any horrid misconfigurations, has been on spindle and stripe element / size sizing.

Not many outside of the upper end SAN guys have seen, first hand, the performance implications of spindle and stripe modifications. Usually, this is the case since these guys are the ones that have access to SAN equipment to test these configurations.

There is open debate on the effect of stripe sizing and many sources of information that provide conflicting info. The most useful document on disk/stripe tweaking I’ve found has been Microsoft’s Disk Performance whitepaper. However, MSFT’s SQL Server Predeployment IO best practices whitepaper, even being less storage specific than the first, mentions good practices.

For example, I was able to improve and reduce a DW/DM load time by a factor of 7, (to 3 hrs), by following, and extensive testing, of MSFT’s spindle and striping recommendations. Not many sources address disk stripe element and full stripe length in sufficient detail. They should because when it comes to IO concurrency, load distribution is huge.

Major Storage Points
-Concurrent IO
HBA Queue Depth settings. Set to max. Most SAN array vendors have custom HBA firmware that will max this setting. Also, Windows has a concurrent IO setting for physicaldisk. SQL might bypass this setting, but something of interest.
-Network paths
For SAN, attempt to supply as many end-to-end paths to meet desired IO concurrency. If using a CDP facility, and performance is a major concern, enable SCSI write ack spoofing on the SAN switches to avoid added latency. Also, if SAN extension via IP is in place make sure to evaluate TCP performance using vendor supplied utilities. Tweak as necessary.
-Operation fragmentation
Avoid it. As usual, never fragment a request/response when performance is a major concern. Size the disk allocation unit, Layer 2 Frame Size, Layer 3 MTU (for IP transports), Array RAM cache page size, Array disk stripe element size in a succession of encapsulation able to finally carry, in it’s entirety, the IO request/response *.
-Critical Array Operations
Critical meaning scary. Try not to overload a SAN with maintenance jobs, such as snaps, clones, replication, and try to support an extreme high performance DB at the same time. Simple IO math. If extensive use of CDP/replication is used to remote Arrays, and the organization has 50-100K to spend , consider offloading that investing in SAN fabric based replication.
Also, review Array RAM cache management policies and tweak as necessary. Exhaustion and subsequent all-stop flush of cache to disk is obviously horrible for performance. Set a more aggressive cache flush policy, usually by percentage used. If spindles and disk stripes were sized appropriately this aggressive cache policy shouldn’t hurt,…much.

All I can think of at the moment. Good luck on the book!

* This is a point of contention. Some sources say to size to accommodate the average IO request size. Some say to instead max out the file system alloc units (MSFT) and disk stripe element size (MSFT, et al). I’ve tested this and I have to agree with MSFT that this method is excellent for high throughput when high number of spindles are involved.

I assume you were referencing the old Peanuts bit:

http://www.snoopy.cpilgrim.com/images/books/darkstrm.jpg

Right?

When you sell the movie rights to your SQL thriller, can I play the psycho killer “Dead Lock”?