06-11-2014 01:46 AM
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,
Solved! Go to Solution.
06-11-2014 02:06 AM
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?
06-11-2014 02:06 AM
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?
06-11-2014 02:23 AM
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?
06-11-2014 02:27 AM
Latest and greatest is nearly always recommended by SYMC if an issue is encountered.
I tend to agree, as it makes troubleshooting 'better'.
06-11-2014 02:32 AM
Thanks, will apply the update and then report back.
06-11-2014 02:40 AM
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.
06-11-2014 03:59 AM
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?
06-11-2014 04:01 AM
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.
06-11-2014 04:11 AM
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.
06-11-2014 09:44 AM
06-11-2014 11:30 PM
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.
06-12-2014 02:04 AM
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.
06-12-2014 02:12 AM
Good news :)
06-19-2014 01:33 AM
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>