Forum Discussion

JumbleSale's avatar
JumbleSale
Level 2
13 years ago

Poor? archiving performance, EV9

Hey guys, I had a support call open with symantec a while back but I just want to put this out to a wider audience and see what kind of real world performance you guys are getting.

In an 8 hour nightly window the best throughput we have had in a night is 10GB, this to us seems quite paltry but we where assured this was a normal figure, more worryingly some evenings we have had 5/6GB and recently even as low as 2GB.

Does this sound normal to you? if not where would you be looking? hardware wise both exchange and the EV side are pretty beefy. Unfortunately we don't have the reporting/monitoring side licensed/installed.

Product Version: 9.0.1.1073
Platform / OS Info: windows server 2008 R2

 

Thanks!

  • OK so first of all

    1. Run a report mode against the users, see how much is genuinely there to archive in the report.
    I know this sounds redundant, but people look at the age of items or the size of the mailbox and think that EV Should be archiving more, but there can be subtle things in the policy such as don't archive unread items, age limits, and stuff like that.

    Also if you don't lock down your policies, users could be setting folders to do not archive, or they could be suspending their mailbox altogether.

    Another thing is EVPM if you decided to customise things such as don't archive sent items, or changing different policies there.

    2. Check the Event Logs
    Although sounding obvious, its a critical thing to check, if you experience errors, especially against something like Exchange 2010, you maybe seeing MAPI errors where the task goes to sleep for 10 minutes, and if you get 6 of those for the same task in a row, well, you have just lost an hours worth of archiving. On the EV Server look for 3310, 3305 and 3301 errors.

    Also check the Event Logs on the exchange server too, if you are running Exchange 2010, there are different mechanisms such as the Throttling Policy which dictates how much and for how long Enterprise Vault will spend in a CAS server, in AD, how many connections etc.  If EV breaches that policy then the Exchange CAS Servers will forcefully close the connection.


    3. Make sure you are running the correct version of Outlook
    If you are running Exchange 2003 and 2007 *only* then you only need run Outlook 2003 as it is somewhat more performant than Outlook 2007.    If you are running Exchange 2010 then you need Exchange 2007 with the performance hotfix released just over a year ago.

    If you do not have the performance hotfix you will suffer performance issues and disconnects purely from a MAPI standpoint, make sure you do not have Outlook 2010 installed on the server as you will see a big degredation in performance as well as it just not being supported on the server.


    4. Don't overload your servers
    Typically in a large environment, you should not want more than 5 archiving tasks on a server at once.
    MAPI itself typically starts to see MAPI Mutex errors and memory leaks when it goes over 32 connections, by default a single Archiving task will use 5 simultaneous MAPI connections, so if you have lots of tasks, you may breach 32 connections and cause slow downs and errors there.


    5. Know what your environment is doing
    Make sure you know how your environment is properly set up, especially with things such as provisioning and synchronization sechedules, if you have a lot of users and a lot of tasks, and the schedules all run in to each other, you can cause a lot of delays and in large enterprise environments a provisioning task can eat in to the schedule of the archiving task.

    Also look at other things that you may be running such as Moved Shortcut Updates, Retention Category Updates, Delete Empty Folders or anything else that may be known to cause slow downs.

    For instance with Shortcut updates, they will run before anything is archived from a mailbox, and depending on how many shortcuts there , it can take a long time


    6. Examine the MSMQ's
    In the Computer Management, check your MSMQ's to see how much is in there, especially on the A5 queue, because when an a task starts up and starts archiving an exchange server, all eligible users will be posted in to the A5 queue.

    If there are items still in there from overnight then it would seem to suggest it may not have been able to process all the users in a single night, but before jumping to that conclusion check the date and time of the oldest item, if you see items that were posted at the very beginning of the archiving schedule then this indicates a problem.

    However mailboxes will typically be posted multiple times to an MSMQ because of the Items Archived Per Pass setting in the Exchange Mailbox task.

    So by default EV will archive 1000 items per pass, meaning it will connect to the mailbox, scan each message to see if its eligible for archiving, sort by size and then date of the email, and then archive 1000 messages. If it knows there are more than 1000 messages to archive it will simply Re-Queue the item.

    So if you have a schedule between 12:00AM and 3AM, and you have a user in the MSMQ posted at 2:59AM, then thats typically OK, it does mean there was more to archive, it just means that it was posted 1 minute before the schedule stopped.


    As well as the above there are other things you should probably be checking
     - Disk Queue Lengths on the Exchange Server, just like anything else, if the disk is slow, then accessing items will be slow
     
     - Network connectivity between the EV server and the Exchange Server, sometimes there can simply be a bad routing, a bad cable, a bad NIC Binding (such as the Backup NIC's being the primary connection) that can make things slower than need be

     - Check the SQL Server processes looking for any blocking or locking that maybe causing queries to run slower, and the disk queues on there as well.
     

8 Replies

  • What are the hardware specs of your enterprise vault and SQL servers ?

    How much data is available to archive ?

  • Perfromance is a tricky tricky subject because there are so many determining factors.  Ultimatley how do things measure up against the performance guide?

    http://www.symantec.com/business/support/index?page=content&id=DOC2817

    70KB messages 8 processors does about 4GB an hour. 

    Larger the message this slows things down.

    How many hours you acutally archive?

    Have you looked ibnto increasing number of archiving threads?

    For example if a controlled test was done with a mailbox that had 4GB of 70K unique items with no other archiving taking place how long does this take. 

    Have you the Symantec case number?

  • I guess you should start at the basics and look as to whether it's something more to do with the fact that based on policies, is there really all that much to archive to begin with?
  • Wayne, thanks for that article link, I will get the SQL guys to check that out their end.

    KeyPlayer I've upped the threads yes but it made no difference, we have a mixed environment with some VMs so I'll look into that, Case number was 415-955-361

    JesusWept2 yes, theres a shedload to archive at 10GB a night it will take ages :(

    Thanks for your help everyone.

  • JubleSale:

    Please specify the specs of your EV environment (cpu/memory/disks) and if it is running fysical or virtual.

  • OK so first of all

    1. Run a report mode against the users, see how much is genuinely there to archive in the report.
    I know this sounds redundant, but people look at the age of items or the size of the mailbox and think that EV Should be archiving more, but there can be subtle things in the policy such as don't archive unread items, age limits, and stuff like that.

    Also if you don't lock down your policies, users could be setting folders to do not archive, or they could be suspending their mailbox altogether.

    Another thing is EVPM if you decided to customise things such as don't archive sent items, or changing different policies there.

    2. Check the Event Logs
    Although sounding obvious, its a critical thing to check, if you experience errors, especially against something like Exchange 2010, you maybe seeing MAPI errors where the task goes to sleep for 10 minutes, and if you get 6 of those for the same task in a row, well, you have just lost an hours worth of archiving. On the EV Server look for 3310, 3305 and 3301 errors.

    Also check the Event Logs on the exchange server too, if you are running Exchange 2010, there are different mechanisms such as the Throttling Policy which dictates how much and for how long Enterprise Vault will spend in a CAS server, in AD, how many connections etc.  If EV breaches that policy then the Exchange CAS Servers will forcefully close the connection.


    3. Make sure you are running the correct version of Outlook
    If you are running Exchange 2003 and 2007 *only* then you only need run Outlook 2003 as it is somewhat more performant than Outlook 2007.    If you are running Exchange 2010 then you need Exchange 2007 with the performance hotfix released just over a year ago.

    If you do not have the performance hotfix you will suffer performance issues and disconnects purely from a MAPI standpoint, make sure you do not have Outlook 2010 installed on the server as you will see a big degredation in performance as well as it just not being supported on the server.


    4. Don't overload your servers
    Typically in a large environment, you should not want more than 5 archiving tasks on a server at once.
    MAPI itself typically starts to see MAPI Mutex errors and memory leaks when it goes over 32 connections, by default a single Archiving task will use 5 simultaneous MAPI connections, so if you have lots of tasks, you may breach 32 connections and cause slow downs and errors there.


    5. Know what your environment is doing
    Make sure you know how your environment is properly set up, especially with things such as provisioning and synchronization sechedules, if you have a lot of users and a lot of tasks, and the schedules all run in to each other, you can cause a lot of delays and in large enterprise environments a provisioning task can eat in to the schedule of the archiving task.

    Also look at other things that you may be running such as Moved Shortcut Updates, Retention Category Updates, Delete Empty Folders or anything else that may be known to cause slow downs.

    For instance with Shortcut updates, they will run before anything is archived from a mailbox, and depending on how many shortcuts there , it can take a long time


    6. Examine the MSMQ's
    In the Computer Management, check your MSMQ's to see how much is in there, especially on the A5 queue, because when an a task starts up and starts archiving an exchange server, all eligible users will be posted in to the A5 queue.

    If there are items still in there from overnight then it would seem to suggest it may not have been able to process all the users in a single night, but before jumping to that conclusion check the date and time of the oldest item, if you see items that were posted at the very beginning of the archiving schedule then this indicates a problem.

    However mailboxes will typically be posted multiple times to an MSMQ because of the Items Archived Per Pass setting in the Exchange Mailbox task.

    So by default EV will archive 1000 items per pass, meaning it will connect to the mailbox, scan each message to see if its eligible for archiving, sort by size and then date of the email, and then archive 1000 messages. If it knows there are more than 1000 messages to archive it will simply Re-Queue the item.

    So if you have a schedule between 12:00AM and 3AM, and you have a user in the MSMQ posted at 2:59AM, then thats typically OK, it does mean there was more to archive, it just means that it was posted 1 minute before the schedule stopped.


    As well as the above there are other things you should probably be checking
     - Disk Queue Lengths on the Exchange Server, just like anything else, if the disk is slow, then accessing items will be slow
     
     - Network connectivity between the EV server and the Exchange Server, sometimes there can simply be a bad routing, a bad cable, a bad NIC Binding (such as the Backup NIC's being the primary connection) that can make things slower than need be

     - Check the SQL Server processes looking for any blocking or locking that maybe causing queries to run slower, and the disk queues on there as well.