Freigeben über

Large Messages Affect Server Performance

  • Artikel

I recent months we have seen issues where users (knowingly or unknowingly) send messages with LARGE attachments (500+mb.) Unfortunately this has huge impact on the server's performance, typically causing message queues to backup and general client sluggishness. I wanted to point on some of the things going on behind the scenes and what can proactively done about it and what we are doing about it...

When a client submits a message the message either lives in memory or is temporarily saved to the Drafts folder depending upon timing. When a user generates a message and attaches a large file to it, the attachment begins streaming to the server. It is only when that process is done and the message is sitting in the drafts folder does the message size count against mailbox storage limits. If user is able to generate a message, attach a large file, and then 'SEND' the message before being completely streamed to the server, the message submission attempt is allowed even if the user current mailbox size + the new message size exceeds the user’s storage limits. If the user is configured to save messages in their Sent Items folder and mailbox size limits are in place, the user will likely realize their error when the attempt to send another message since there mailbox is then over the size limit.

When a message is submitted, or sent, a property is stamped on the message by the client indicating the size of the message. The Information Store checks the size of the message against the user's individual maximum message size submission limits. This information is cached when the user first logs on to Exchange and fully refreshed every 2 hours. To adjust the lifetime of the various mailbox caching mechanisms, take a look at the following KB article:

https://support.microsoft.com/default.aspx?scid=kb;en-us;327378

If the message exceeds the individual limit, the Information Store rejects the submission from the client and the client then receives an error message to the affect “This message exceeds the maximum message size limits for this user“. However, when no individual limits are imposed, the message is accepted by the Information Store and placed into the Temp Tables while the message stub information is sent to the Categorizer. When the Categorizer examines the message it looks to see if the message size exceeds the Global Maximum Submission Limit, and if so, creates an NDR message and attaches the original, large message, to the NDR. This process in essence generates a new message containing the old message. The NDR is then sent back through the Information Store to the user that originally sent the message.

Currently there is a setting to prevent the NDR process from attempting to attach such a large message:

https://support.microsoft.com/default.aspx?scid=kb;en-us;308303

We are also current working on a Hotfix that changes some behavior during the submission process. With this fix, the Information Store now changes some of the logic of how it maintains limits. As I mentioned above, when a user initially logs on to Exchange, we query information about the user from the Active Directory. If the user has individual message size limits, those limits are cached as part of the user’s logon. If the user does not have individual limits, then we read the Global Maximum Submission Limit value and apply that value to the user’s limits. By making this slight change, we can prevent a large message from being submitted for delivery and clogging the pipes. If in some rare circumstance the Individual Limits are larger than the global limits, the message will be allowed to be ‘Sent’ from the client, but when the message reaches the Categorizer, may still NDR.

More details about this fix are available from the following articles. Note the first article, 830762, is a released fix that starts to address this issue. I minor problem was found after the fix was released that may cause the limits to be reverted when background quotas are refreshed. The final fix correcting that problem should be available in 3 weeks and is referenced by the second article below, which has yet to be released.. You can currently call PSS for the first fix, 830762, however it be likely 3-4 weeks before the final fix (836738) is available.

https://support.microsoft.com/default.aspx?scid=kb;en-us;830762
https://support.microsoft.com/default.aspx?scid=kb;en-us;836738

Comments

  • Anonymous
    March 01, 2004
    Thanks for the explanation

  • Anonymous
    March 02, 2004
    One thing I've asked for in the past is the ability to apply things like message size limits or mailbox limits through a GPO at the OU level, this is especially necessary for ASP's that seperate paying customers into different OU's in AD and may have different size limits based on what the customer pays. Setting these at the store level is to broad (why give a customer with 30 seats their own store?), and having to set it for each individual user is too much of a pain. This could also be very usefull for large enterprises that want to set different types of limits per department/group, and also a different set of limits for workers/managers/executives.

  • Anonymous
    March 03, 2004
    In our organization, it can be attachments of the 20 to 50+ MB size that clog the queues. We had a HUGE problem with that, until we turned off pipelining. With pipelining turned off, the queues still back up, but they clear out much faster once the large message is streamed....

  • Anonymous
    March 03, 2004
    Welcome to my web wanderings :: Large Messages Affect Server Performance

  • Anonymous
    March 05, 2004
    Exchange-faq.dk - Din portal til Microsoft Exchange Server information

  • Anonymous
    May 20, 2004
    Any update regarding 836738 being released?

    Also, are these hotfixes available for Exchange 2003?

    Thanks.

  • Anonymous
    April 19, 2006
    Recently we have been seeing several issues in Support Services where Event ID 623 is being logged on...

  • Anonymous
    May 02, 2007
    Recently we have been seeing several issues in Support Services where Event ID 623 is being logged on...

  • Anonymous
    June 07, 2008
    PingBack from http://caleblocalnews.325mb.com/thismessageexceedsthemaximummessagesizeallowedexchange2007.html

  • Anonymous
    June 07, 2009
    PingBack from http://weakbladder.info/story.php?id=5138

  • Anonymous
    June 12, 2009
    PingBack from http://jointpainreliefs.info/story.php?id=2479

  • Anonymous
    June 18, 2009
    PingBack from http://thestoragebench.info/story.php?id=5415