Hi Running EV9.0.2 When importing PSTs via EVPM, Event 6742 (PST Migration Report) shows an import speed between 65 and 157 MB/hour. This is painfully slow. Our archiving servers are pretty beefy, backend storage is an EMC Centera. Any ideas/recommendations? Thanks

Update to this: With all of the EV tasks (archiving, provisioning, moving) stopped on ServerB (the server with the storage for the mailboxes I am importing to), I got 480.75 MB/Hour. Still seeing high CPU utilisation on server. Doing the import on a different, under-utilised EV server, 730.02 MB/Hour (even though the storage service is on a differnent EV server). That is more acceptable. So solution for us is: Import on a juicy server with plenty of CPU and ideally not doing any other EV tasks and ideally containing the EV storage service for the mailbox(es) you’re importing into.

EVPM import - horrendously slow spped

12 Replies

AndrewB
Moderator
13 years ago
do you have centera collections configured for your EV servers? there's some tuning that you can do for that too. you also might want to check if any discovery searches or exports or anything else is going on at the same time that would impact your system performance.
goatboy
Level 6
13 years ago
Yes, we use Centera collections. What tuning is recommended? Something specific to collections or perhaps something like number of archive processes for the storage service?
AndrewB
Moderator
13 years ago
are you seeing any errors in the event logs on the EV server(s)? you'll want to run a trace to see which part of the process is taking a long time and then go from there.
Prone2Typos
Moderator
13 years ago
you specified your issue is with PSTs imported through EVPM. Have you tried via just importing the items from teh VAC to see if you are getting the same rate? I would assume you are. I also agree with Andrew in stating that you will likely need to check the trace to see where your perf issues are. Centera collections should not matter too much for storage rate as shoudl be writing to an NTFS location first which should account for the completed storage of an item. The only real way to determine what is causing you a slow-dwn (assuming no events) is via DTrace and excerpting the trace on a per thread basis to see if you can identify a pattern of slowness. You could also go top-down and ensure that SQL and Stoage are healthy and not queueing or having locks (SQL).
Rob_Wilcox1
Level 6
13 years ago
For what it's worth - I just tried a couple of 500 Mb (ish) PST files, using locate/collect/migrate from a client machine up to the server, in some 'rusty' VM's. I am using EV 10.0.1.

I don't have collections of any kind enabled.

The speed I am seeing is : 770 Mb/hour. But it does vary wildly depending on the size of the items in the PST.

Hope that helps in some way.
Rob_Wilcox1
Level 6
13 years ago
Was anything else needed on this issue?
Jeff_Shotton
Level 6
13 years ago
For reference there is an option to increase the concurrency of PST migrations via EVPM, as detailed in the Utilities guide. This may improve overall speed:

in the [PSTDefaults] section:

ConcurrentMigrations
Optional. Specifies the maximum number of concurrent PST migrations. This
setting takes effect only if MigrationMode is set to Process.
Possible values:
■ An integer in the range 1 to 25. The default is 10.

Regards,

Jeff
Rob_Wilcox1
Level 6
13 years ago
Interesting Mr Bond.
goatboy
Level 6
13 years ago
I have an open case with Symantec, they want to run a test import with the vault cache disabled, to see if that helps, I will post updates when this is done. Thanks for following up.
Rob_Wilcox1
Level 6
13 years ago
hmm is your migratorserver process horrendously busy then at the moment (with vault cache builds) ?