Forum Discussion

Mark_Tkachyk's avatar
13 years ago

Archiving very slow on new install

I'm doing a brand new install of EV 10.0.2 - 1 server (virtual) with 4 cpus and 16 GB RAM, SQL on a separate server and Exchange 2010.    After the install completed, we selected the first mailbox.   A Run Now in Report mode took 3 minutes to complete and told us taht there were 56K messages to archive (2496 MB).    I figured this should take an hour or so.  I next did a Run Now in Archiving and Shortcut mode and it worked -- but it took about 9 hours!    There were no errors and the performance was fairly consistent.    I ran a dtrace to see what was going on but nothing was jumping out at me.   After a couple of hours, I remembered tht we hadn't configured the A/V exclusions so we fixed that, rebooted and restarted the manual archive.   Performance didn't improve.   CPU load was under 5% and the message queues were empty.   It only archived between 4500 and 5000 messages an hour @ average size 50K/msg.

I know that the recommended minimum server configuration is now 8 cpu cores but they insisted on going with 4 and it isn't the bottleneck right now.   My next guess would be that it can't read the data from Exchange fast enough, but we ran the throttling script before we started archiving and verified that the archiving task started without any errors.   The partitions are on a network share but the storage queue was always at 0 while I was watching so I don't think that is the bottleneck either.

Does anyone have suggestions on how to narrow this down?

 

thanks,

Mark

  • Well the thing is te CPU is really only going to spike on storage processing and content conversion, but if its a single thread and its just handling a steady stream of email, i wouldnt expect it to go all that fast.

    The thing is theres a ton of moving parts, SQL Server (its own disk IO, network bandwidth, CPU usage), and the same on the exchange server and same on the EV Server. It could be SQL Server slowing down, it could be exchange performing some kind of maintanance etc

    The issue really is that MAPI isn't tremendously fast in the first place, and you might just be seeing the limit of what exchange can do for a single mailbox anyway, but still might be worth just seeing what kind of loads you are seeing on the exchange side of things especially with disk queue length