email backed up in Submission Queue “mailbox database thread limit exceeded”

Issues:
email is backing up in the Exchange Submission Queue and the following errors are displayed in Queue Viewer:
432 4.3.2 storedriver component has been retired
432 4.3.2 STOREDRV.Deliver; mailbox database thread limit exceeded

Processor is also pegged at 100% or close to it on the hub transport server

Potential causes of this issue for others but were not the cause in my cause:
-exceeded mailbox size quotas on the database, especially a journal mailbox / database
-under-powered Hub Transport servers

One cause confirmed:
The EMC SAN housing the active database copies had a failed power supply battery and an disabled write-cache, impacting disk I/O performance.

Resolutions Attempted:
— considered reducing max message size from 30MB to 20MB

— Added the following key into EdgeTransport.exe.config file and restarted the transport service on CAS1/CAS2 (may only want to do this temporarily if the HUB transport is not on a separate server):
<add key=”MailboxDeliveryThrottlingEnabled” value=”False” />
location of EdgeTransport.exe.config: C:\Program Files\Microsoft\Exchange Server\V14\Bin\EdgeTransport.exe.config

— In a highly utilized environment like my customers Hosted Exchange environment, it may be worth considering having dedicated hub transport servers and dedicated journaling servers if journaling is in use. The following limits can be increased without impacting CAS or DB performance:
<add key=”RecipientThreadLimit” value=”2″ />
<add key=”MaxMailboxDeliveryPerMdbConnections” value=”3″ />
For more information see: https://blogs.technet.com/b/exchange/archive/2011/04/11/store-driver-fault-isolation-improvements-in-exchange-2010-sp1.aspx)

— Increased Processors and RAM in Hub Transport Servers

— Activated database copies on Mailbox server that had fastest disk I/O. Remember, the EMC SAN housing the active database copies had a disabled write-cache, negatively impacting disk I/O performance.

Conclusion: I found that increasing processors and RAM and activating the databases on the Mailbox Server with the fastest disk I/O made the most positive impact on the problem and the queues gradually emptied.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.