Forum Discussion

BlueBull's avatar
BlueBull
Level 4
11 years ago

EVPM PST Migration casuing Server Reboot

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,

Enterprise Vault
Information Governance
Troubleshooting
Windows Server (2003-2008)
  • Rob_Wilcox1's avatar
    Rob_Wilcox1
    11 years ago

    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?

  • Rob_Wilcox1's avatar
    Rob_Wilcox1
    Level 6
    11 years ago

    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?

  • BlueBull's avatar
    BlueBull
    Level 4
    11 years ago

    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's avatar
    Rob_Wilcox1
    Level 6
    11 years ago

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

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

  • Manoj_Chanchawa's avatar
    Manoj_Chanchawa
    Level 3
    11 years ago

    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's avatar
    BlueBull
    Level 4
    11 years ago

    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's avatar
    BlueBull
    Level 4
    11 years ago

    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's avatar
    Manoj_Chanchawa
    Level 3
    11 years ago

    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's avatar
    JesusWept3
    Level 6
    11 years ago
    What's the actual blue screen stop code though? It could be something like bad memory as opposed to an actual coding issue
  • Rob_Wilcox1's avatar
    Rob_Wilcox1
    Level 6
    11 years ago

    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.