SQL Server Performance Forum – Threads Archive
Multiple Arrays on One Controller ?
I’ve seen it recommended to have different arrays and raid levels for OS, Logs, and Db, my question is should each of these arrays be on a separate Array Controller ? We have a Dell PERC 3 Controller with 2 Channels and 12x36Gb drives in an external drive cage. The channels are split so they can’t mix streams. On one channel we have 1 array: Raid 5 for the database (D). On the other channel we have 2 arrays: Raid 0 for transaction logs (G) and a flat drive for staging backups before sending them to tape (J). There is another PERC 3 Controller with 2 Channels and 2x36Gb drives on the backplane. This has 2 channels. On one channel is a Raid 1 array for the C drive (OS). The other channel is unused. If using one controller is ok, I don’t think the arrays are configured correctly between the channels anyway. We are experiencing slowdowns at times that don’t appear to coincide with increased load on the database. These slowdowns show large Avg Disk Queue lengths for the D drive (max 734 this am) these appear to be primarily reads (The Avg Disk Read Queue is almost idential). Any advice on configuring this would be very helpful thanks Brian ReynoldsThe problem is not, at first, separate Array Controller.
If Avg. Disk Queue is > 2 for a long time, the razon is Database is on RAID 5. You will get more performance if you cant put DB on RAID 10.
RAID 5 is faster reading but not writing. If you cannot do that (may be space problem), run Profiler to find recomendations to improve preformace. Luis Martin
I agree Raid 10 would be a good step, but our problem is with a large Read Queue so wouldn’t Raid 5 be less of a problem in this case ? The real key answer I’m looking for is: How reasonable is it to have 3 raid arrays on one controller split between 2 channels? Could this perform like having 3 logical drives on one disk ? Or is it more likely to perform like 3 drives on separate disks ? It seems like it should act like 3 drives on separate disks because they are 3 arrays using 12 physical disks, but it’s not behaving that way. thanks Brian Reynolds
One comment – Do not keep Transaction Log on Raid 0 as this is not recommended for high availability. Gaurav
Moderator
Man thrives, oddly enough, only in the presence of a challenging environment- L. Ron Hubbard
I’d suspect that large queues for reading point to a memory problem… Are you able to use perfmon to track both memory|pages/sec and the SQL Server buffer|Read pages/sec (names of counters are from memory) Both should average close to zero over a longer period of time How big are your databases? How much memory do you have in the box? What else runs on the box? SQL should be caching information reasonably efficiently when all is well… 3 arrays on a single controller is perfectly ok, although it does give you a single point of failure and isn’t quite as optimum for performance. Not as bad as logical drives within a physical drive though… Also as Luis mentioned, run SQL Profiler to identify RPCs/batch completions taking more than say 100ms to complete and investigate if this is reasonable… Disk subsystem problems are not THAT common, usually the problem is application, memory, cpu or network (in inverse/exponential decreasing likelyhood) Cheers
Twan
]]>