EVPM import - horrendously slow spped

[goatboy]

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

[AndrewB]

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]

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]

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]

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]

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]

Was anything else needed on this issue?

[Jeff_Shotton]

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]

Interesting Mr Bond.

[goatboy]

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]

hmm is your migratorserver process horrendously busy then at the moment (with vault cache builds) ?

[goatboy]

Don't believe so. One issue I suspect is not helping things is that PSTs are on serverA, I run EVPM on serverA and import runs on serverB because of .ini file.

When I specify serverB in the EVPM file, import works, albeit sloooowly.

When I specify serverA in the EVPM file, I get this error:

Event 6469

An exception has occurred.

[Internal reference CMigrator::StartWorking/ce]

[goatboy · Accepted solution]

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.