Hi Bru

The latest EV Performance Guide states the following based on a average message size of 70 KB per hour

Number of CPUs   Wizard-assisted (single process)   Locate and Migrate/Scripted

2 CPUs                           15,000                                                                    25,000

4 CPUs (including 2 × dual processor) 15,000 40,000

2 quad-core processors    15,000           60,000

The reality is most PST messages are bigger that 70 KB so I would safely half this amount .I have been involved in several PST ingestion projects and have seen speeds from 2-4 GB an hour.Hope this helps.PST migrations are slow projects in my opinion :)

Sorry the table paste came out wrong :)

Please take the 40,000 and 60,000 numbers and put them under Locate and Migrate/Scripted Column

Ok thanks Bruce. The 2-4GB per hour figure is the one that I'm interested in. That's reasonable enough.

I guess we're in for the long haul then!

Bru,

another FYI in terms of real world #s.  We are in the beginning stages of a large pst migration using EVPM.  The EV Servers are 2CPU W2k8 in VM with Centera so we are not talking bleeding edge performance.  In this environment we are getting roughly 1.5GB/hour with a large mix of PST sizes.  I would say this is at the low-end of the performance scales.  My colleagues regulary see the 2-3GB/hour rate with faster hardware.

Please pay special attention to the Concurrent Migrations settings in EVPM.  General recommendation is 2 threads per CPU but we found 3 threads (for 2 virtual CPUs) hits 100% and stays there during the migration.

-Joe

Thanks Joe, I'll bear that in mind. 2-3GB does seem to be the magic number.

Did you consider installing extra, temporary EV servers to run EVPM? Would it be easy to decommission temporary EV servers when all the PSTs are imported? Or can EVPM run on a non-EV server or one without all the components?!

I guess that the Centera could handle the load. Our SQL databases are on a SAN and all our machines are physical. We're using W2K3 though.

- Alan.

Alan,

We did not consider a temp EV server.  One of our other guys has a great procedure for using a roving EV server for remote PST migrations but this was a brand new install of Exchange, EV, Centera, etc (migration from Domino) so the benefit wasn't there.

EVPM must be run on an EV server and ideally from the EV server that manages the target users' archives.  The procedure my colleague created is a bit of a trick to get around this but we chose to stay in fully Symantec supported mode in the event of errors.  12,000 PSTs across 3 EV servers I figure we'll get ~3-4GB/hour combined with the 3 servers.

The fun part with EVPM is its unforgiving nature.  Make a one line mistake and the whole script bombs out.  I've written a wrapping batch process to ensure the system is ready for each PST before adding it to the nightly run.

-Joe

Thanks for the tips Joe. I guess we better stay in supported mode as well.

Just one other question if you don't mind:are you only doing PST imports at night-time? I was hoping to do

imports during the day as well but do you find that the performance unacceptable is for users during the import?

And can you manage to do an online-mailbox archive run at the same time as importing the PSTs? I presume

you need a backup window too.

- Alan.

5gb PST import - 2h15m on a quad core e5450 @ 3ghz with 4gb ram on 2k3. EV 8.0. This was my latest on a console-driven PST import (manual). Might not be apples to apples for you, but it's some real-world numbers at least. =) Seems to jive with what others are seeing too.

Alan,

We start them at night after the MBA run finishes and let it run for ~12 hours (1am -1pm). The PST migration is NOT creating shortcuts so there is not performance hit on Exchange.  So far no user complaints on performance but we only have about 300 people using the system so far.  I imagine this will change.  If you are going to run it during the day maybe tweak down the concurrent migrations to 1.  This should lesson the stress on the system at the cost of slowing down the migration.

I strongly recommend against a MBA run at the same time.  This will bring EV to its knees and I would be very concerned of mapi overload.

For example we see occasional (1 or 2x /hour) error:

Abnormal error occurred with the Memory Mapped Stream object
Name: C$1$SRC

Reference: OMPF/CF

This error does NOT appear to be fatal and seem to be self-correcting (ie auto-retry succeeds) but we are monitoring it.

-Joe

... getting the PST files to the server.

The manual work of going to each user, turning off their auto archive and disconnecting existing PSTs before you copy them to your central repository, etc is a big chunk of manual labor.

You would think that client-driven would solve most things like password-protected PSTs, PSTs in read-only mode, etc.  but the checkpoint/restart capability in EV 7.5 SP4 is still iffy, in my experience. 

How did you manage to get all the PST files collected and all those users' hands held?

Thanks!