NTFS to Centera Migration -- Huge throughput degradation

[wren_mott1]

Hi eveyrone -

We are running the migration tool against a 200gb partition.  Yesterday we were seeing a throughout of 5GB, however today we are seeing 400MB of throughout per hour.  The network is not congested and there is no other activity (backups, archiving, etc.) on the server.

We are collecting this data by restarting the storage service every once in awhile which causes the tool to write to its log.  What is interesting is that the log entries now seem to be abbreviated. Now when we restart the storage service the log no longer reports the savesets per hour metric even though it appears that some messages are being migrated.  Unfortunately, at a rate of 400MB an hour our migration will take close to a year.

Has anyone lese run into this?  Can I kill the current migration job and recreate it?  Will it start from where the cancelled job left off?

Wren

[Maquiladoras · Accepted solution]

Restarting the storage will be detremental to this operation for the fact that when you start storage we end up querying the Vault Store database in chunks to see what items have been exported, so the sql will loop over items until it gets to the end of the table.

we've seen in the past that these sql queries end up taking the majority of the time, and that it will migrate items as and when it finds them.

Best thing to do is to dtrace StorageDelete process which handles the NTFS to Centera migration, log it out and lets have a look at a sample of what it is actually doing.

Also i take it there are no visible errors in the event logs?

[wren_mott1]

Thank you for the reply.  I don't suppose there is another way to gather throughout data other than restarting the storage service is there?  I will DTRACE and post it back to the group.

Thanks again!

Wren

[wren_mott1]

Hi Again -

I didn't wnat ot post the whole trace, but after searching it I came across a "ton" of these "errors."

CSavesetOnIStg::ReadStreamedPropertyBin _com_error exception reading streamed property.|Property Name: CHGuid|hr=%1 could not be found.  [0x80030002]

Savesets still seem to be copying although at a much slower pace.  Is there error anything to be concerned about?  Can anyone decipher?

Thanks again!


Wren

[Maquiladoras]

That error is a red herring, and is not the cause of this issues, you'd see that error being posted in most operations, however its not critical, not a show stopper, hence not being posted to the EV event logs.

Also when you start the job, don't you get an option of how often it will update the TXT file?

If you find somewhere where we can download the DTrace, we can see where the bottleneck is, it could be sql, the source or the centera, but only the dtrace will tell us that