cancel
Showing results for 
Search instead for 
Did you mean: 

EVPM PST Migration casuing Server Reboot

BlueBull
Level 4
Partner Accredited

Hi,

I am running EV version 10.0.4.1189 and am performing a large PST migration via EVPM. The server is a VM running 2008 R2 and has PST temp location which is ISCSI attached.

Within my INI file I have CONCURRENTMIGRATIONS set to 10. Some of the smaller migration sets, with a few PST files, complete without error. On the larger migration sets, current one has 349 PST files, the process runs for a while and then the server reboots and creates a memory dump.

After expecting the dump I notice that the following modules are faulted:

Execute-Worker

EVConverterSAN

MigratorServer

Has anyone ever experienced this before or knows of a solution?

Regards,

1 ACCEPTED SOLUTION

Accepted Solutions

Rob_Wilcox1
Level 6
Partner

Which OS is the server on? Have you upgraded the server to CHF3?

EVConverterSandbox does often fault in normal operations. Don't know what Execute-Worker is, unless it's part of IIS..  MigratorServer is 'the one' doing your ingest.

 

Perhaps you're just overloading 'stuff'. Have you tried *5* concurrents?

Working for cloudficient.com

View solution in original post

13 REPLIES 13

Rob_Wilcox1
Level 6
Partner

Which OS is the server on? Have you upgraded the server to CHF3?

EVConverterSandbox does often fault in normal operations. Don't know what Execute-Worker is, unless it's part of IIS..  MigratorServer is 'the one' doing your ingest.

 

Perhaps you're just overloading 'stuff'. Have you tried *5* concurrents?

Working for cloudficient.com

BlueBull
Level 4
Partner Accredited

The OS is Windows 2008 R2. I have not updated to CHF3 as yet.

I will try the 5 concurrent processes.

Would it be a recommendation to apply CHF3?

Rob_Wilcox1
Level 6
Partner

Latest and greatest is nearly always recommended by SYMC if an issue is encountered.

I tend to agree, as it makes troubleshooting 'better'.

Working for cloudficient.com

BlueBull
Level 4
Partner Accredited

Thanks, will apply the update and then report back.

Manoj_Chanchawa
Level 3
Employee Accredited

Agree with Rob here, latest is best.

Execute-Worker process is from Indexing world. is your indexing running while you are migrating PSTs? whats the memory usage\number of threds related of indexing related processes? Also, if you can share more info from dumps, it may help. 

BlueBull
Level 4
Partner Accredited

The server runs at an avg of 65% cpu and 12Gb Memory utilization when performing the PST ingestion. Yes indexing is running at the same time of PST ingestion. Would this cause an issue?

Also the config of the server is as follows:

2.7 Ghz CPU with 16 cores

32GB of memory

So with this config and utilization, the server is guaranteed not overloaded. Would you agree?

BlueBull
Level 4
Partner Accredited

Oh yes caching is set on its on LUN, as well as MSMQ data and Log. Temp Location has been moved off the default C drive location.

Manoj_Chanchawa
Level 3
Employee Accredited

Yeh, server didnt seem to overload. Indexing running in parallel is not an issue.

The dump details you gave earlier, pointing to some processes related to Indexing or content conversion, so I guess, there may a chance that your server is not rebooted due to PST migration process, but due to some exception in Indexing or content conversion which is happening in parallel. Saying this, can you paste initial analyse of dumps and dtrace of Indexing\content conversion processes? Second, go through event logs to find if there is any error reported, whcih can give you further hint. This may help to narrow down the issue.
Else, opening a Symantec support can be another option. 

JesusWept3
Level 6
Partner Accredited Certified
What's the actual blue screen stop code though? It could be something like bad memory as opposed to an actual coding issue
https://www.linkedin.com/in/alex-allen-turl-07370146

Rob_Wilcox1
Level 6
Partner

JW3 is right.  I had similar on a machine which I run some VMs on.  All lab stuff, but the principle applies.  Soon as I started a 3rd VM it would blue screen.  Therefore, I incorrectly thought it was a virtual machine problem or something specific with that one.

 

But it was bad memory.

 

Figured out which it was took it out, no more problems.. replaced it with a new one, still going strong.

Working for cloudficient.com

BlueBull
Level 4
Partner Accredited

Thanks for all the replies. Yesterday I applied the CHF3 for 10.0.4 and started the ingestion of 349 PST files. Size of the PST files were 1.2TB. It is still runing at this time without any crash or reboot.

 

It seems the CHF3 resolved the issue. I will be testing another batch soon and will update the thread.

Rob_Wilcox1
Level 6
Partner

Good news :)

Working for cloudficient.com

BlueBull
Level 4
Partner Accredited

Hi All,

 

After some extensive testing, the reboot and the faults are still occuring. Here is the XML from the fault on the EVSandboxCnverter. Does anyone know why this will happen?

 

<?xml version="1.0" encoding="UTF-16"?><WERReportMetadata><OSVersionInformation><WindowsNTVersion>6.1</WindowsNTVersion><Build>7601 Service Pack 1</Build><Product>(0x7): Windows Server 2008 R2 Standard</Product><Edition>ServerStandard</Edition><BuildString>7601.18409.amd64fre.win7sp1_gdr.140303-2144</BuildString><Revision>1130</Revision><Flavor>Multiprocessor Free</Flavor><Architecture>X64</Architecture><LCID>1033</LCID></OSVersionInformation><ParentProcessInformation><ParentProcessId>45652</ParentProcessId><ParentProcessPath>D:\Program Files (x86)\Enterprise Vault\MigratorServer.exe</ParentProcessPath><ParentProcessCmdLine>"D:\Program Files (x86)\Enterprise Vault\MigratorServer.exe" -Embedding</ParentProcessCmdLine></ParentProcessInformation><ProblemSignatures><EventType>APPCRASH</EventType><Parameter0>EVConverterSandbox.exe</Parameter0><Parameter1>10.0.4.1189</Parameter1><Parameter2>51dd9548</Parameter2><Parameter3>StackHash_4af9</Parameter3><Parameter4>6.1.7601.18247</Parameter4><Parameter5>521ea8e7</Parameter5><Parameter6>c0000374</Parameter6><Parameter7>000ce753</Parameter7></ProblemSignatures><DynamicSignatures><Parameter1>6.1.7601.2.1.0.272.7</Parameter1><Parameter2>1033</Parameter2><Parameter22>4af9</Parameter22><Parameter23>4af97dcafcf4d227d7a317eeecf55d3b</Parameter23><Parameter24>6c6a</Parameter24><Parameter25>6c6a67774beca66b8649f81ece895747</Parameter25></DynamicSignatures><SystemInformation><MID>911CEFC9-D722-4595-9DB2-91B14250C53F</MID><SystemManufacturer>VMware, Inc.</SystemManufacturer><SystemProductName>VMware Virtual Platform</SystemProductName><BIOSVersion>6.00</BIOSVersion></SystemInformation></WERReportMetadata>