January 2, 2013 at 11:12 am
As already mentioned increase the number of threads for your tests, also increase the queue depth (outstanding IOs) to around 32 or 64 and run for around 5 mins at a time.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
January 2, 2013 at 11:16 am
sql-lover (12/18/2012)
Any feedback and opinion is highly appreciated ... my main interest is discovered any potential problem, if one, prior going live and before installing the SQL 2012 fail-over instance.
Depending on the HBAs installed in the server they could have a theoretical throughput of 200MBs, you're not even getting near half of that.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
January 2, 2013 at 11:50 am
Perry Whittle (1/2/2013)
As already mentioned increase the number of threads for your tests, also increase the queue depth (outstanding IOs) to around 32 or 64 and run for around 5 mins at a time.
Hi Perry,
What am I going to accomplish with that? Given the current file size and settings, results are pretty much accurate, in my opinion.
What I do not get, is why increasing the allocation unit will improve the overall latency or disk performance. I do not see why or at least, would like to see the technical explanation for that.
January 3, 2013 at 3:41 am
If it's not windows 2008 you will need to set the offset also for the drive.
January 4, 2013 at 7:58 am
sql-lover (1/2/2013)
Hi Perry,What am I going to accomplish with that? Given the current file size and settings, results are pretty much accurate, in my opinion.
The HBA queue depth (or outstanding I\Os) dictates how many I\O requests may be active for that bus adapter.
Higher queue depth = increased throughput.
Don't raise it to high though or you'll just saturate the storage sub system and that's often worse than setting too low.
sql-lover (1/2/2013)
What I do not get, is why increasing the allocation unit will improve the overall latency or disk performance. I do not see why or at least, would like to see the technical explanation for that.
The file allocation unit size alone will not have much effect, it's closely related to the stripe size and the partition starting offset. See this link for more info.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
January 7, 2013 at 7:58 am
Wow,
I asked our SAN expert to review the LUN configuration with me. And this was his response: "latency will go up once we go live, as this is a shared storage"
I should mention that our new SAN at work uses automated storage tiering, but based on my experience, latency values should be higher than what I'm getting.
Am I missing something here?
January 7, 2013 at 12:04 pm
Hi SQL-Lover 🙂
I've been watching the responses given since our last discussion on this.
Theoretical limits are always nonsense as a SAN is a shared device (if the disks aren't, the SAN cache, fabric etc certainly is!).
I would ask your SAN man (always think of Metallica when I say that haha!)...about....Multipathing. Is it being used? Is it configured correctly? etc etc
Might be worth looking at a third-party product like EMC PowerPath to utilise all your paths correctly for full MP fun 🙂
Good luck - just to share - I haven't gotten far with my SAN fun here.... turns out whoever scoped up and put our SAN configuration together forgot to add ANY future proofing. So as soon as we add Exchange to the mix my SQL servers are screwed..... We've going to look at Powerpath to give us that bandwidth we need (and to see how much room it gives us in the throughput).
Cheers
Viewing 7 posts - 16 through 21 (of 21 total)
You must be logged in to reply to this topic. Login to reply