cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted

A5 queue showing multiple request for same mailbox

Hi All,

I am facing a wierd issue on 1 of our EV 9.0.2 server archiving Exchange 2003 mailbox. The server currently archives only 1 large group mailbox approx 40 GB and every it gets stuck in scheduled archiving.

Upon investigation I found A5 queue shows 2 Archive mailbox request for the same mailbox. Refer to the screenshot in attachment.

Dtrace shows the following error indicating a conflict in the queue :-

89305    11:08:24.439     [12628]    (ArchiveTask)    <8628>    EV:H    :CArchivingAgent:Smiley TonguerocessUser() |Archive/Journal Task ignored a Process Mailbox Message because the Process Mailbox mutex was locked and the mailbox is being processed by another thread |

I am not able to figure out how 2 A5 request showing for the same mailbox. I have to purge the A5 queue everyday to get the mailbox archived.

Any ideas??

 

 

 

 

 

1 Solution

Accepted Solutions
Highlighted
Accepted Solution!

Thanks Merv for your

Thanks Merv for your suggestion. I involved Symantec Support to have a look and they suggested to Dismount and Mount the Mailbox database on which the problem mailbox was hosted. I also found the mailbox contains 2 million NDR mails of few KBs in addition to 2 million shortcuts which could also contributing to the slow processing. 

After remounting the database the Process Mutex error went away. Hence we can close this thread.

View solution in original post

5 Replies
Highlighted

That indicates that the

That indicates that the mailbox cannot be handled within the schedule. When the schedule starts again, it puts a new request in a5, but the old one is being continued. You're best bet is to wait until the mailbox is at an acceptable level, then the a5 should behave normal again.

Regards. Gertjan
Highlighted

The trick to doing large mbx

The trick to doing large mbx is NOT to depend on schedule archiving. Typically it goes through a pass by pass method of 1000 items at a time. Being 40gb that may translate to hundreds of thousands of times and lots and lots of passes. I would do manual archiving runs.first run report mode. Do a test for 10,000 messages. See how long it takes..than go full steam by doing all messages and delay your scheduled archives for a day or 2. Going by 70-100k an hour it may take a day or 2 days if your rate is half that ( also remember to exclude your backup window and backup mode.)
Highlighted

Thanks for your suggestion

Thanks for your suggestion Merv. I followed your adivce and did Run Now on 10000 item and it completed in half a day. Now I did a Run Now on all items its still running but the archiving rate is very slow only 400-500 items per day!!

The mailbox server does not have any other mailbox other than this large one. I saw a warning to rebuild the rebuild VSDB SQL Indexes in the event log which is applicable to our environment as we have Centera paritions. However I am not sure if rebuilding SQL Index will speed up the archiving rate.

Also I noticed Archive Task hardly consuming any CPU 1-10% . Any suggestions are welcome.

 

 

Highlighted

If there is literally just 1

If there is literally just 1 mbx than scheduled or run now should not make much diff Yes for perf issues first and easiest option is to.ensure sql main is done so index defrag or rebuild and then uodate statistics. Do a check of current index frag levels first which is mentioned in the section"Verifying successful completion of the SQL Server maintenance plan" then.do that again after the sql maint job. Note skip the shrink db/ t-logs http://www.symantec.com/business/support/index?page=content&id=TECH74666 Ok just be sure that the reason its doing so little per day is not a policy issue check mbx archiving reports for the eligible items. Is it only 500? You may need a more aggresive age like only keep 2 weeks.mail + large items first policy That 10k items in half a day is way too slow too..so I suspect other issues..connectivity to the target is a biggie. I/o to target exchange db and network latency. Try to open up the mbx you are targeting/archiving from the outlook client on the EV server and try copying a few hundred items out to PST. If that is slow too...than the issue is the exchange server or network speeds
Highlighted
Accepted Solution!

Thanks Merv for your

Thanks Merv for your suggestion. I involved Symantec Support to have a look and they suggested to Dismount and Mount the Mailbox database on which the problem mailbox was hosted. I also found the mailbox contains 2 million NDR mails of few KBs in addition to 2 million shortcuts which could also contributing to the slow processing. 

After remounting the database the Process Mutex error went away. Hence we can close this thread.

View solution in original post