RE: Allocation Unit (Cluster) Size Question
You might consider the book Scaling Microsoft Exchange 2000: Create and Optimize High-Performance Exchange Messaging Systems by Pierre Bijaoui from Comp^h^h^h^hHP. There are also a couple MEC presentations around that he did that dive into this pretty thoroughly. Correct tuning of your disks can result in up to a 4x I/O delta. Now, not all of this is done in stripe size; part of it is in the RAID level you choose and the number of spindles. You may find that just adding a couple more spindles makes more difference than any chunk/stripe size changes. Don't focus as much on the exchange database drive though. Most of the activity there is reads and they're cached pretty efficiently by the OS. You can note that the EDB file grows in 1MB chunks, so perhaps that's a reasonable number to work with. If you want to impact perceivable performance, tune the log drives to improve the synchronous write performance. Also note that if you're bottleneck is not the drives, no amount of I/O improvement will change the user experience. In other words, if your existing disks support N I/O operations per second and your users are only driving it to N/4, improving to 2N makes no difference to the users. === Andy Webb[EMAIL PROTECTED] www.swinc.com Simpler-Webb, Inc. Austin, TX512-322-0071 -- Eating XXX Chili at Texas Chili Parlor since 1989 -- === -Original Message- From: Martin, Jon [mailto:[EMAIL PROTECTED]] Posted At: Monday, June 17, 2002 11:57 AM Posted To: Microsoft Exchange Conversation: Allocation Unit (Cluster) Size Question Subject: Allocation Unit (Cluster) Size Question Exchange writes to the database in 4k pages. This being the case, does it not make sense to format database drives in 4k Allocation Units (clusters)? And beyond that, since my RAID controller gives me the ability to control the stripe size, shouldn't make this 4k also? Get everyone (database, OS and hardware) in 4k harmony, so to speak. On a similar track regarding transaction logs, if we have valid information as to the average size of messages in our system, would there be a performance boost by configuring the transaction log drive to use clusters and stripes close to (but a little bigger) that the average message size? Or, do I have no clue as to how these things work (always a possibility)? Thanks . . . _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED]
RE: Allocation Unit (Cluster) Size Question
I don't use the word much, but this is an awesome book. Tweakers nit pickers will have months of fun implementing the millions of useful recommendations in this book. In the same way that you should not trust a default Windows implementation to be secure, you should not trust it to be optimized for performance, either. This book tells you why, and how to get the most from your hardware OS. And the answer to the original question is: I was close. Keep the write size (4k for Exchange db), cluster (allocation unit) size and RAID stripe size in sync. What I was not thinking of is the RAID stripe size applies to the amount of data written in one contiguous chunk to each disk in the array. There is a corollary number to plug into the equations - the stripe width, which is the number of drives in the array which data is written to. So if I read this correctly, you would want the RAID stripe size to be 4k divided by the stripe width. Keeping it simple, if you had four drives in a RAID 0 array, the correct stripe size to match the 4k Exchange database writes would be 1k. The fact no one would run Exchange in RAID 0, and that you would really have eight drives in a RAID 0/1 array does not change the optimum stripe size in this example. Additional performance? Sure. Enough to re-config a production box? Probably not, unless you have a high degree of tolerance for risk and pain. Good to know for new boxes, though. Now if we can just get someone to spend a bunch of time testing this all out in their lab, and report back. -Original Message- From: Martin, Jon Sent: Monday, June 17, 2002 4:17 PM To: Exchange Discussions Subject:RE: Allocation Unit (Cluster) Size Question Already on order. Thanks. Jon -Original Message- From: Ray Zorz [mailto:[EMAIL PROTECTED]] Sent: Monday, June 17, 2002 4:12 PM To: Exchange Discussions Subject: RE: Allocation Unit (Cluster) Size Question Then get the Curt Aubley book mentioned previously. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Martin, Jon Sent: Monday, June 17, 2002 4:01 PM To: Exchange Discussions Subject: RE: Allocation Unit (Cluster) Size Question Actually, my boss prefers that I get the most out of the money he spends on hardware and software. When I ask a group of knowledgeable folks a question concerning a little documented but potentially useful way to increase system performance, my boss sees that as a useful expenditure of my time. Trading shots with someone who has indicated she really doesn't know the answer probably would not meet his idea 'useful expenditure of time', but he will probably get over it. -Original Message- From: Baker, Jennifer [mailto:[EMAIL PROTECTED]] Sent: Monday, June 17, 2002 2:37 PM To: Exchange Discussions Subject: RE: Allocation Unit (Cluster) Size Question If performance is really an issue maybe you should consider different hardware configurations. For instance, RAID 0+1 instead of RAID5, use more disks in your RAID array to spread the data access, faster disks, higher end controllers with more R/W cache, etc. To worry about negligible performance (probably .01%) increases while investing actual productive time probably means you need your boss to assign you more work. Unless, of course the time you spend measuring all the differences in performance while tweaking your system with different configurations actually translates to no extra cost. -Original Message- From: Martin, Jon [mailto:[EMAIL PROTECTED]] Sent: Monday, June 17, 2002 12:55 PM To: Exchange Discussions Subject: RE: Allocation Unit (Cluster) Size Question Uh, if I understand you correctly, you are not much interested in tweaking a few easy (during system installation, anyways) settings to optimize (at no extra cost) the performance of your system. Jon -Original Message- From: Baker, Jennifer [mailto:[EMAIL PROTECTED]] Sent: Monday, June 17, 2002 11:32 AM To: Exchange Discussions Subject: RE: Allocation Unit (Cluster) Size Question If I understand you correctly, you are talking about some nit-picky settings that probably will have very little, if any, affect on performance. -Original Message- From: Martin, Jon [mailto:[EMAIL PROTECTED]] Sent: Monday, June 17, 2002 9:57 AM To: Exchange Discussions Subject: Allocation Unit (Cluster) Size Question Exchange writes to the database in 4k pages. This being the case, does it not make sense to format database drives in 4k Allocation Units (clusters)? And beyond that, since my RAID controller gives me the ability to control the stripe size, shouldn't make this 4k also? Get everyone (database, OS and hardware) in 4k harmony, so to speak. On a similar track regarding transaction logs, if we have valid information as to the average size of messages in our system, would there be a performance boost by configuring the transaction log drive to use clusters and stripes close to (but a little bigger
RE: Allocation Unit (Cluster) Size Question
This topic seems to arise every other year or so since early in Exchange 4.0. There is a heated debate on e-mail, with no-one really proving anything. Then it all goes quiet. At least this time we seem to have two valid approaches for those that want to bother. A book by Curt Aubley and a website at Tricord. I agree with Ed. I would like someone with more time than most of us have, go out and investigate this in a real-world situation. Then report back here, there and everywhere (MEC) to let the rest of us know whether we were right or not in not worrying about it. Cheers, Chris -Original Message- From: Ed Crowley [mailto:[EMAIL PROTECTED]] Sent: 18 June 2002 05:01 To: Exchange Discussions Subject: RE: Allocation Unit (Cluster) Size Question I would recommend that you beat this to death in the lab and then present your findings at the MEC. I would truly be interested (no sarcasm, really) if there were any significant difference. Ed Crowley MCSE+Internet MVP kcCC+I Tech Consultant hp Services Protecting the world from PSTs and Bricked Backups! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Martin, Jon Sent: Monday, June 17, 2002 4:01 PM To: Exchange Discussions Subject: RE: Allocation Unit (Cluster) Size Question Actually, my boss prefers that I get the most out of the money he spends on hardware and software. When I ask a group of knowledgeable folks a question concerning a little documented but potentially useful way to increase system performance, my boss sees that as a useful expenditure of my time. Trading shots with someone who has indicated she really doesn't know the answer probably would not meet his idea 'useful expenditure of time', but he will probably get over it. -Original Message- From: Baker, Jennifer [mailto:[EMAIL PROTECTED]] Sent: Monday, June 17, 2002 2:37 PM To: Exchange Discussions Subject: RE: Allocation Unit (Cluster) Size Question If performance is really an issue maybe you should consider different hardware configurations. For instance, RAID 0+1 instead of RAID5, use more disks in your RAID array to spread the data access, faster disks, higher end controllers with more R/W cache, etc. To worry about negligible performance (probably .01%) increases while investing actual productive time probably means you need your boss to assign you more work. Unless, of course the time you spend measuring all the differences in performance while tweaking your system with different configurations actually translates to no extra cost. -Original Message- From: Martin, Jon [mailto:[EMAIL PROTECTED]] Sent: Monday, June 17, 2002 12:55 PM To: Exchange Discussions Subject: RE: Allocation Unit (Cluster) Size Question Uh, if I understand you correctly, you are not much interested in tweaking a few easy (during system installation, anyways) settings to optimize (at no extra cost) the performance of your system. Jon -Original Message- From: Baker, Jennifer [mailto:[EMAIL PROTECTED]] Sent: Monday, June 17, 2002 11:32 AM To: Exchange Discussions Subject: RE: Allocation Unit (Cluster) Size Question If I understand you correctly, you are talking about some nit-picky settings that probably will have very little, if any, affect on performance. -Original Message- From: Martin, Jon [mailto:[EMAIL PROTECTED]] Sent: Monday, June 17, 2002 9:57 AM To: Exchange Discussions Subject: Allocation Unit (Cluster) Size Question Exchange writes to the database in 4k pages. This being the case, does it not make sense to format database drives in 4k Allocation Units (clusters)? And beyond that, since my RAID controller gives me the ability to control the stripe size, shouldn't make this 4k also? Get everyone (database, OS and hardware) in 4k harmony, so to speak. On a similar track regarding transaction logs, if we have valid information as to the average size of messages in our system, would there be a performance boost by configuring the transaction log drive to use clusters and stripes close to (but a little bigger) that the average message size? Or, do I have no clue as to how these things work (always a possibility)? Thanks . . . _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin:[EMAIL PROTECTED] _ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe
