Share via


Mail.que growth

Hello All,

Working in support sector we see a lot of different cases opened every day.

One of the most call generator these days is that the customer after moving to Exchange 2013,2016 are experiencing a larger mail.que growth and mostly worried about the same.

The general statement that comes from exchange customer is that i have never seen my mail.que grow this much in 2010 is this normal.

Well, I would like to clarify this first

Generally  the growth of the mail.que depends on the following factors:

1.Safety net time

2.Average mail size in the organization

3.Average mail flow in the organization

4.Maximum queue days

5.Percentage of the message queued

 

  • The Safety net hold time is how long the message gets retained in the mail.que after the message gets delivered (this was introduced in 2013)
  • The size of the mail.que growth can be given by the formula:
  • Overall Transport DB Size = average message size x overall daily message traffic x (1 + (percentage of messages queued x maximum queue days) + Safety Net hold days) x 2 copies for high availability
    1. This must be divided further by the number of databases and their copy
    2. Comparing these parameters, you would understand how large the queue grows per day and whether it is normal or not.
    3. I would like to note a point out here after the mails in the mail.que get delivered it will not reduce in size only an offline defragment will reduce in size.

So the next question that comes in is that if this eats my drive space faster how can i control the growth.

    1. You can control the growth of the mail.que by changing the parameter of safety net hold time in the transport configuration by using the set-transportconfig .(i would prefer a value of 2 days)
    2. Also you can change the online de-fragmentation schedule by changing the parameters in the Edgetransport.exe config file
    3. <add key="QueueDatabaseOnlineDefragSchedule" value="1:00:00" />
    4. <add key="QueueDatabaseOnlineDefragTimeToRun" value="3:00:00" />

The above key signifies that every day run my online de-fragmentation for 3 hours

If you still feel that this grows too much in size

    • One workaround to the problem is that you can pause the transport service and ensure that the queue is 0.
    • Then stop the transport service and delete the mail.que file and start the transport service.
    • This will create a new mail.que file and it will help in overcoming you issue
    • This can be done one server at a time hence has no downtime for creating a new mail.que.

 

If you have any questions feel free to comment.

AC

Comments

  • Anonymous
    September 26, 2016
    Thanks for sharingdeinetly interesting stuff
  • Anonymous
    October 03, 2016
    thanks fot sharing
  • Anonymous
    October 11, 2016
    Excellent!!!