This post is more than 5 years old
225 Posts
0
2413
Recommendation or BP TimeOutValue setting, Exchange environment?
This question comes to me, after reading this blog on MSDN, http://blogs.msdn.com/b/san/archive/2011/08/15/the-windows-disk-timeout-value-understanding-why-this-should-be-set-to-a-small-value.aspx
And I also learned Exchange 2010 and its SP1 has made change on it IO behavior and MS recommend set TimeOutValue to 20s on DAS and SAN or follow HW vendor’s recommendation.
I like to know what’s EMC recommend value on it? And if a Exchang on EFD, could we have a less value to have better performance?
Thanks,
Eddy
Tx1_f906d5
21 Posts
0
May 16th, 2012 05:00
Eddy, you raise some questions ... so let me provide some answers.
Disk Timeout: "I like to know what’s EMC recommend value on it?" The answer is that we do not recommend changing this value from it's default value at this time. There will always be exceptions to the rule .. but that's the point right there .. they are the *exception*, not the rule.
Why? Because this value represents what Windows will do with I/Os that are "lost" - a request was sent, and the I/O has not returned. There are multiple components in the I/O stack, not the least of which is MPIO (in general EMC PowerPath will be the DSM for our customer deployments)'. When an I/O does not have a return in time, there's somethng rather wrong in the environment, and while reducing the timeout, this does nothing for performance ... which is really your second question.
Performance: "if a Exchang on EFD, could we have a less value to have better performance?" As mentioned, the Disk Timeout value, is a setting to determine when the I/O shoudl be considered lost. For a system to get to this point, something is wrong in the environment. Lowering this value is not going to make I/Os happen any faster. In fact, I/O operations would hope that they never get to this point. The goal, and implemention of the I/O stack is to make I/Os happen as fast as they possibly can.
To summarize .. if a customer is finding that they have timeout issues, they should work with the appropriate Customer Support Organization (EMC's if that's the most apporpriate path). The CS organization will work on the issue and make determinations as to what steps should be taken, up to and including registry changes that would alter default values.
DButch1
15 Posts
0
May 14th, 2012 15:00
Windows Server 2008 and Server 2008 R2 are still using the default timeout value of 60 seconds. It was arrived at after a lot of discussion and testing between Microsoft and their storage partners like EMC. For arrays, it insures that we ride throught the worst case upgrade scenario without causing I/O failure.
The discussion in the article is a bit overstated - database management applications like SQL (and Exchange) already have their own I/O timers and will log warnings and errors if critical I/Os don't complete in considerably less than 60 seconds. A lot of other I/O problems like media/connect failures will create an explicit and immediate error rather than wait passively for a timeout.
I consider the idea of extremely delayed recognition of a problem due to setting the timeout to 60 seconds to be something of an edge case with very low probability of occurence EXCEPT for the array upgrade situation (normally planned for a low load period).
Regards,
Butch
reseach
225 Posts
0
May 15th, 2012 20:00
http://blogs.technet.com/b/exchange/archive/2011/11/17/windows-disk-timeouts-and-exchange-server-2010.aspx
I found this article, you might look at it.
Timeout is method to protect host from IO bus reset storms( not for “array upgrade situation”) , the article’s conclusion tends to suggest to set timeout value lower on SAN, because of RAID parity.
Eddy
reseach
225 Posts
0
May 16th, 2012 19:00
Tx, thank for your clarification and information. I will take your comment as my understanding of TimeOutValue.
Followup question, for now shall I use 60ms, DButch mentioned default windows setting, or 20 ms, recommended by the former MS article on Exchange over SAN environment?
Thanks,
Eddy
Tx1_f906d5
21 Posts
0
May 16th, 2012 20:00
Eddy, the short answer is, unless you know what you are doing, or *need* to chage this because you have been instructed by a support organization to do so ... Leave it at the default ... you know, that value that was there BEFORE you started to change it.