Morning. BDM accounts for 7.5 MB/s per database based on Jetstress. So the result should be trusted. Total Bandwidth increase by ~3x with BDM from 3.5MB/s per DB without, to 11MB/s with BDM enable.

The only concern is if the 7.5 MB/s per database effected by original throughput(3.5MB/s).

Lu

I tend to agree with you - BDM is a developer-contrived workload. There’s no reason (and indeed no way) for them to correlate BDM workload to the production workload, and for us to size as if they do doesn’t make much sense.

This technet article says that BDM is “approximately” 5MB/s/DB.

My hypothesis is that the BDM rate is correlated to CPU clock speed. Something along the lines of “issue a 256KB read every XXX clock ticks”. This hypothesis would explain why we see it gradually increasing over time. I’ll bet if we did a comparative analysis (in production), we’d see a direct relationship between clock speed and BDM-related bandwidth. Unfortunately, this means that sizing for BDM will always be a moving target.

Paul,

Thank you for input it was helpfull

For those of you that didn't see it; Ross had a blog post last week on BDM.

http://blogs.technet.com/b/exchange/archive/2011/12/14/database-maintenance-in-exchange-2010.aspx

Near the bottom he sticks this section in...

"Database checksumming can become an IO tax burden if the storage is not designed correctly (even though it's sequential) as it performs 256K read IOs and generates roughly 5MB/s per database.

As part of our storage guidance, we recommend you configure your storage array stripe size (the size of stripes written to each disk in an array; also referred to as block size) to be 256KB or larger."

Bryan,

Thank you the article was very good. and explained a lot, thanks for sharing