Odd RAID performance

[sirebral]

Hello all,

There's a lot of back story here, yet I'll try an condense. We're running an OpenE SAN on a Dell 480 <-- think that's correct. OpenE didn't play nicely with the Perc 6i, so we replaced it with an LSI SAS 9265-8I with a GB of NV Cache, which it does seem to like much more and is natively supported in the SAN software.

We're running a Hyper-V cluster with SQL as one of the guests, which is where we're having the issues. I'm running with 4 port MPIO to the SAN device and showing some great performance, yet where we're lacking is SQLIO(mostly 8K fully random operations), which reports high latency on READ functions (85% over 24ms), yet is well within the acceptable range for writes (exceeding the performance of the old physical box). For this I am ruling out the logical disk layout (RAID-50 in two sets striped across 8 disks).

Write back is enabled on the card, adaptive read-ahead enabled, disk cache disabled. Latest firmware has been loaded as well.

I haven't worked with the LSI cards much, more of an HP person, I'm used to being able to adjust the read/write cache allocation, yet LSI doesn't seem to present this option. Is it there yet hidden somewhere in the CLI?

What I'm looking for is anything that I can try to get the read to match the write with this card, any input is appreciated.

Thanks all,

Keith

 

[blakerwry]

The only cache settings on the LSI cards are the ones you've already mentioned: write-through vs write back and cached io vs direct io. The majority of the card's cache is used for write operations, and read operations would largely come from your (Open-E) system RAM (if applicable) or from disk.

The cached io option does imply that some amount of caching can come from the controller cache, but the default is to disable this feature and I have not found it to offer much improvement in my own experiences with PERC(LSI) cards either. Your OS can probably use system RAM much more effectively rather than using the card's RAM to cache reads anyway.

This knowledge probably doesn't help your situation much however. I can say that I do not experience the same slowness on my systems (DAS with various PERC cards) which perform heavy SQL usage. We typically stick to RAID10, ext3/ext4, and MySQL. The biggest performance factors for SQL tend to be db optimizations like indexes and table layout, with RAM and CPU being next, and lastly disk. If you already have optimized your db (or cannot due to application limitations) then I would suggest making sure you have enough RAM to hold your entire db contents and have configured sql to use it appropriately.