large number of savesets taking too long to clear

[smlopes]

This weekend we had close to 2 million savesets, the most we ever had seen in weeks.The A3 queue appearently was still running and held the savesets from clearing/processing. Is there a way to clear up the savesets quicker?

[AndrewB]

you probably want to investigate what was causing the process to back up in the first place. maybe your archiving parameters are too aggressive for the system to keep up with. maybe the storage is bogged down by another processs. could be a load of things but that's how i would look at it.

[RahulG]

You may try to set the number of concurrent archiving threads higher.You do this on the archiving task .

Check the policy is set properly and Ev is not archving the items which are not eligible for archiving

(Note :a3 queue is for the run now operation)

[Percy_Vere]

Do you actually mean that you had 2 million pending items that were waiting to be post processed? i.e turned from a clock icon into a shortcut. The A3 Q having lots of items in it due to someone performing a run now on lots of items would cause a delay in normal archiving (A5 Q). I would suggest that you monitor the performance of the EV server whilst doing run nows on users mailboxes or limit the use of manual archiving.

You may also want to review your archiving policy because if it it too loose then users will have a lot of old emails that are not archived and will thefore manually archive causing the A3 build up.

[smlopes]

We had EV configured for 9 threads, 250 items per pass. Archiving policy is set to archive items older than 30 days. It seems that it totally ignored our settings...

[smlopes]

On SQL server, we added more RAM, increased page file and updated SQL 2008 SP2 to cumulative 6 Friday night to increase performance. Evault server settings and policies weren't modified. EV was in backup mode during the maintenance, then cleared after maintenance. We have archiving scheduled, no manual archiving performed that Fri night. We are adding 2 more CPUs on EV tonight to increase performance. My guess is that we improved SQL 10x better that Evault server couldn't keep up.

[smlopes]

Yes, post process. A3 queue only had like 2000 items, not many. Our policy is set to archive anything older than 30 days.

[MarkBarefoot]

the A1 queue has the highest priority when looking at the MSMQ, and that's where the pending items are converted to shortcuts. Not sure why you have your archiving task set to 9 threads with a pass of 250 items - that's a 1/4 of the default messages per pass.

The A3 queue is Manual Run Now requests - this shouldn't have many, if any, items on it as the scheduled job (A5) should be doing most of the work.

[JesusWept3]

I don't know if you got past this or not, but 2 million items sounds like you may have breached the 1GB Quota set by default on MSMQ and thus MSMQ literally just stopped processing any requests, if you make it bigger that would probably kick start the process

Also 9 threads per task is overload, especially if you have multiple archiving tasks on a single server, typically MAPI starts to show mutex errors, timeouts etc when it goes over 32 connections, so if you have 4 tasks all set to 9 threads in one shot, you're doing 36 connections in one go that may not be helping things at all

[smlopes · Accepted solution]

Stopped A3 MSMQ, then everything returned to normal...weird...