Just upgraded from 7.5 to 8.01 and A5 Q processing is SLOW

[psimp]

After upgrading form 7.5 sp2 to sp5 and then to 8.01 the A5 queues process about 100 out of 6000 during a 10-12 hour window. Before all archive processing would complete in 3-5 hours. We have 2 Exchange 2007 targets running on 2003 sp2 64 bit. EV server is 2003 r2 sp2 with 8 gb ram. We have about 1200 mailboxes being archived. Before upgrade during archive runs you could refresh MSMQ and watch the A5's continually process/empty. Now it processes about 1-3 an hour. I have sent logs to Symantec support the past 2 days with no resolutions but tech notes and reg changes we have previously seen and made. Is this normal for the 1st archive run after upgrading? Is there that many changes being made to the DB that processing would be this slow? Box is running around 5-11% cpu usage and low mem usage as well. System definitely not being maxed out. And yes we do see the "dreaded 3310" events now and then and have stepped through all the tech notes for that event as well. BUT 8.01 has been very stable for the users as opposed to 7.5. Centera storage IS growing by about 2-3 gb's a night as opposed to 10-15 GB before. Sorry for the length of message but I wanted to explain well. Also I'm still waiting to hear back from Sym support on last dtrace.

[TonySterling · Accepted solution]

Do you have Delete Orphaned Shortucts checked?  If yes uncheck it and restart the archive task.

There was a similiar past awhile back.

https://www-secure.symantec.com/connect/forums/msmq-not-clearing

[psimp]

Sure do and thanks for the link. I've been going through the forum just not enough I guess. I'll uncheck "Delete orphaned shortcuts" and let you know how the archive tasks run tonight. Also with the 3310 is there anyway to increase the timeout value that causes this error? And once again appreciate the info!! I'll pass it along to support. ;)

[TonySterling]

Sorry but no the isn't.  what is the actual text of the event you are seeing?  There are a couple different versions.

[Wayne_Humphrey]

Hi psimp,

I tried to get this into best practice, but no one listened to me.  What I suggest you do is create a new temporary Provisioning Group and then update meta-data in a staged approach. Once its got through the entire org then remove the temp prov group as it will take minutes a day once you have got through the backlog.

Does this make sense or do I need to do  tutorial on it so others can benefit?

--wayne

[psimp]

From the archiving tasks and the journal task as well. = event 3310. EV/Exchange/GC all on the same subnet with gb connection and 10gb backbone. Not having to transverse any switches/routers/etc...

There was a problem accessing a network service or resource. The dispenser will re-queue the current item and sleep for 10 minute(s).

[psimp]

Thanks for the replies, I'm testing with a 2 hour window now. And Wayne, yes = tutorial! ;)
p.s. Is it best to purge the a5 and other queues when processing doesn't finish in the scheduled window, or just leave them alone and let them continue on during next archiving run? Consultant has told us to purge and start with fresh Q's. (All except A1 for A Q's)
Thanks!

[Wayne_Humphrey]

Yea,

I would disable "Delete orphaned shortcuts"  purge the lot and start from scratch". What is your "pending shortcut timeout" set to?

--wayne

[psimp]

Pending shortcut timeout is set to 2 (days)

[Wayne_Humphrey]

Then you cool to blast them all away :)

[psimp]

Thanks guy's. It appears to have been the issue. Last 10 hour window processed 156 out of A5. Right now it is processing around 300 an hour. We should be caught up by the end of the 3 day weekend.

[psimp]

Looks like 'Delete Orphaned Shortcuts' was the culprit. Between 55-60 GB's were processed and sent to the Centera's last night. Another run or 2 and we will be caught back up. MUCH appreciated!!