February 18, 2009 at 4:29 pm
Excellent data and analysis Kendal - we have a very similar hardware environment to yours from the sound of it (PE2950s, PV220S and MD1000s).
I don't suppose you'd have the time and opportunity to run a repeat of your Part 5 tests (RAID5 vs RAID10) but with RAID10 using 8 spindles and RAID5 using 4? Eg the same number of stripe members (4). I suspect I know what the results would look like but there's nothing like hard data (wish some of our boxes were not in production so I could test myself).
Eagerly awaiting your Part 7 🙂
Regards,
Jacob
February 18, 2009 at 5:54 pm
G'day Kendal,
When you're writing to either configuration each block is being written to two physical drives at once and the write has to complete to both drives before it is reported as successful. It therefore comes down to how much the disk heads have to travel to do the next write that matters.
In the ideal situation, the next write to the dual-RAID1 configuration would be to the other logical drive (the other physical pair of disks).
In the single-RAID10 configuration then it depends on the algorithm used to spread the data, but again in the ideal situation the next write would be to the other pair of drives.
It therefore comes down to whatever sits in between. The controller might have to do a little more work when there's two logical drives, but we're still talking electronic speeds rather than disk spins and head movement, so it's hard to see it being a bottle-neck in either configuration. Similarly anything up-stream: the physical operation of the disk drives should always be the limiting factor so anything up-stream is always going to be going faster than the physical drives can.
When you're reading then each block is read from only one physical drive, so again there's nothing that can differentiate the two in the ideal situation.
The difference I can see is in pre-allocating random access files, which is how the database files work (the log files are sequential). In the single-RAID10 scenario the disk heads would need to move from one file to the other very regularly, whereas in the dual-RAID1 scenario each drive's heads would never leave it's own file, so there would be less head-travel-overhead.
So in my estimation of the real world the paired-RAID1 database files would be marginally faster (of course, by the time you ran into this limit I'd expect the drive your log file resides on would have melted).
February 19, 2009 at 9:01 am
Nice to see some analysis - but I would say that at least in http://kendalvandyke.blogspot.com/2009/02/disk-performance-hands-on-part-6-raid.html the charts are pretty misleading, you have to look hugely closely at the numbers!
The graphs make out there is a huge difference - because of where you have cut the axes. Naughty, naughty.
🙂
February 19, 2009 at 9:15 am
The graphs make out there is a huge difference - because of where you have cut the axes. Naughty, naughty.
First off, thanks for taking the time to read my blog. If you felt misled I can assure you it was not intentional. I used Excel to create the charts and the axis range was set to auto. I would certainly hope that you - or anyone else who read it - paid attention to the numbers! That's why I made them bold and included the actual values in the graph. In any case, I did make all my results available up front as the first thing I did before I posted any graphs or analysis. See part 1 of my series here: http://kendalvandyke.blogspot.com/2009/02/disk-performance-hands-on-part-1-test.html
Also note that at the end of the post I made it clear that RAID 10 was still the recommended choice.
February 19, 2009 at 9:27 am
Fair enough - but if you haven't read the book I thoroughly recommend it 😀
February 19, 2009 at 9:41 am
RichardB (2/19/2009)
Fair enough - but if you haven't read the book I thoroughly recommend it 😀
I may do that, thanks.
To show you that I do not intend to mislead anybody I have adjusted the graphs so that the vertical axis always begins at 0. In all fairness you were right, and I appreciate the constructive criticism. I will look back at the previous posts in the series and adjust any other graphs that may appear misleading.
February 19, 2009 at 11:19 am
Great blog Kendal (you have way too much time on your hands 😀 )
very informative
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
February 19, 2009 at 3:35 pm
Kendal Van Dyke (2/19/2009)
Perry Whittle (2/19/2009)
Great blog Kendal (you have way too much time on your hands 😀 )very informative
Thanks for the positive feedback!
I posted part 7 this afternoon. Wrapup coming tomorrow.
Very much agreed Kendal! The posts are excellent! Thanks for sharing your testing.
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
February 19, 2009 at 4:38 pm
Kendal i too, did notice the graphs were a little off but paid more attention to the actual numbers
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
January 20, 2010 at 2:18 am
I agree with you Glenn. SQL logs are written sequentially so ideally you'd want to put on its own RAID 1, RAID group. It's okay to put it on a RAID 1/0 RAID group also if you only a single log file. If you have multiple log files writing to the same RAID group then they become random I/O. I've taken the liberty to draw out the two scenarios for those who are visual.
Scenario 1, separate RAID 1 RAID group for multiple logs:
http://xenmaster.com/ISCSISAN2NodesSQLCluster0.aspx
Scenario 2, shared RAID 1/0 RAID group for multiple logs:
http://xenmaster.com/ISCSISAN2NodesSQLCluster.aspx
I prefer to use the first scenario because I/Os are isolated and it's easier to maintain, logically and physically. I welcome all your inputs. Any hardware vendor reading this post please feel free to comment or post your recommendation.
July 26, 2011 at 11:17 am
Do not forget the bandwidth of the PCI bus.
Do not forget the availability of multiple I/O channels in the controller and whether or not any MPIO load balancing is used.
In such circumstances, the only way to fully utilize the bus bandwidth is to present multiple LUNs to the host.
Now, here's the head turner, what to do with those LUNs: should we create separate volumes and use SQL files per filegroup on each or host stripe across both (called a disk plaid)? Very similar to a RAID 1/0, but with the striping RAID 0 performed on the host instead of the array.
Good luck.
Anthony Thomas
Viewing 12 posts - 46 through 56 (of 56 total)
You must be logged in to reply to this topic. Login to reply