EDIT 10/14/2009: We updated the section that recommends settings for environments that need to support messages larger than default 10MB message size.
Already an expert on large messages? You'll still want to check out the updated "Best Practices" section below to harden your server against possible outages.
Although email is not always the best way to share files, the method is frequently used. As an administrator, you probably have to allow messages to be sent with attachments. Sometimes these attachments are relatively large. But you also have to balance this business requirement with making sure that your server hardware does not become overly utilized or that some users are denied service while others are processing super large messages.
In Customer Support Services we see a lot of critical server unresponsive type issues caused by someone trying to attach a really large file, say perhaps someone trying to share a DVD home video .ISO with their friends and coworkers.
Although we've attempted to harden Exchange out of the box, there are still a few things that you should consider doing to further limit the possibility of something like this happening.
It all begins with "reasonable" size limits. So the question everyone asks is "what is reasonable?" The answer is that your mileage will certainly vary with your hardware, drive space, number of users, availability requirements, etc. For Exchange 2007, the typical size limits we see are in the range of 10-30 MB. There are business cases where larger messages are required. However, not all hardware is equally equipped to handle it. Think about the following cases:
Maximum allowed msg size
Maximum allowed number of recipients per message
Typical messages per second
Possible worst case peak scenario
Do you have that kind of space available? Do you want to pay for it? Can your disks keep up with that amount of I/O? Hub transports? Mailbox databases? Transaction log files? Will your archiving and retention systems be able to keep up?
Ok, so obviously this is an extreme case - every message sent is not going to be as large as the maximum limit, and not every message is going to be sent to as many recipients as possible. But you can easily see that message size is an important piece of planning for server sizing and availability. You must plan for both the average case, but also consider the peak/worst case. Even if the same chart were done with averages instead of worst cases, you can imagine that even if just a few large messages make it out per day, the average size goes up considerably. Also, your server has to be able to handle those few per day in a reasonable amount of time. Remember that it is possible to provide limits for one set of users and still allow the occasional large message to be sent by more important folks, say company executives.
Furthermore, if the possibility exists that someone can send a DVD .ISO to everyone in the company, you can bet that it will happen at some point. Will your server(s) handle it gracefully? Or will business stop because of this incident?
Our capacity and planning tools will help you make the decision, although they are designed around the average case - don't forget to at least consider that raising message sizes will not only affect the average case, it will also raise the peak load case. For more discussion on this, see this post.
Exchange 2007 introduces a concept within Transport servers called Back Pressure. You can read all about it here. Suffice it to say, if your server becomes too busy, it will stop accepting new messages, and allow itself time to gracefully recover. It does this to protect itself from the extreme cases.
In short, Back Pressure is Exchange 2007's way of monitoring available disk space, memory and uncommitted messages. When any of those resources exceed their corresponding thresholds for a sustained period the HUB server stops accepting anonymous submissions (medium threshold) or all submissions (high threshold). For example:
Event Type: Warning
Event Source: MSExchangeTransport
Event Category: ResourceManager
Event ID: 15004
Resource pressure increased from Medium to High.
Resource utilization of the following resources exceed the normal level:
Version buckets = 213 [High] [Normal=80 Medium=120 High=200]
Back pressure caused the following components to be disabled:
Inbound mail submission from Hub Transport servers
Inbound mail submission from the Internet
Mail submission from the Pickup directory
Mail submission from the Replay directory
Mail submission from Mailbox servers
Mail delivery to remote domains
With large messages, you have the possibility that a database transaction to commit the message into the database will take some time to complete. During that time, the database is tracking the commit with what is called version buckets or version store. So with large messages, you can guess that version buckets will often be the measure of how the mail queue database is keeping up. A few seconds of back pressure a few times per day is fine, but if your server(s) spend a lot of time in back pressure, then there's the possibility that other messages aren't being processed in a timely fashion.
Let's also take a look at the graph below (Message Size (MB) versus Version buckets). This graph charts the size of the message sent along with the corresponding Version Buckets Allocated while the message was transmitted. The yellow line shows the default medium threshold for Back pressure resource monitoring of 120, and the red line is the default High Threshold of 200. As the message increases, the version buckets allocated continue to increase as well. When the message size reaches approximately 100MB the version buckets allocated have done beyond the medium threshold value of 120. This will cause inbound anonymous SMTP traffic to temporarily be suspended (Internal Hub to Hub and Mailbox submissions will not be affected. This chart shows that Exchange 2007 has the ability for transport to support a single message as large as 150MB without causing internal mail flow disruption - but again, remember, this is an isolated single message going to a single recipient.
Please note that these measurements were taken in the absence of processing a high rate of other smaller messages and it was performed on a server configuration that was I/O constrained (single disk).
For more information about the impact of specific messages on hardware, check out this study.
And for information about the impact of large messages on your mailbox stores, see this post.
Although, you've probably seen this, let's quickly review the common places that size limits are set and discuss possible ways to harden your server(s):
Yawn. You've seen this before, right? Well what about these limits you may not remember?
An ounce of prevention is worth a pound of cure. So here are the best practices we recommend to protect your server(s) from large messages that might cause outages.
<add key ="DatabaseMaxCacheSize" value="536870912" />
For servers with 8GB of RAM or more, particularly if they are dedicated Hub role with transport dumpster enabled, you can set the value as high as 1GB:
<add key="DatabaseMaxCacheSize" value="1073741824" />
<add key="VersionBucketsHighThreshold" value="200" />
<add key="VersionBucketsMediumThreshold" value="120" />
<add key="VersionBucketsNormalThreshold" value="80" />
<add key="DatabaseCheckPointDepthMax" value="268435456" />
Or, with DatabaseMaxCacheSize set to 1GB -
<add key="DatabaseCheckPointDepthMax" value="536870912" />
<add key="QueueDatabaseLoggingBufferSize" value=" 5242880" />
Message size limits will protect your servers and make sure they stay happily running, but there is not any "one-size-fits-all" guidance. Nevertheless, setting reasonable message limits and following the best practices can save you a great deal of trouble.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.