Forum Discussion

BlueBull's avatar
BlueBull
Level 4
11 years ago

EVPM PST ingest causes server reboot

Hi All,

I had this issue a week or 2 ago. I am ingestig 100's of PST files using EVPM. The process works very well.

However, it seems to fault on occasion, faulting EVConverterSandbox.exe. This creates a dump and the server is rebooted.

I have applied the 10.0.4 CHF3 to the environment which appeared to resolve the issue.

But after a while with ingesting more data, the issue reappeared.

In the INI script, I have reduced concurrent ConcurrentMigrations to 6 and the issue still occurs.

Has anyone seen this before? Is there a limit to the number of PST's you can ingest with EVPM in a respective run?

Regards,

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

    EVConverterSandbox is part of the 'indexing process', well in general terms it is (stuff goes through conversion so that it can be indexed).. so not specifically to do with EVPM or PST ingestion.

     

    Random idea .. good if you have a test environment :)

     

    Can you reproduce it in a test environment? If so.. what happens if you stop the indexing service?  All the items should get ingested, and there should be no crash/reboot. 

     

    After that, you could start the indexing service, and see how it handles processing the backlog?  Maybe pushing with EVPM is hitting it too hard (I mean this shouldn't happen, because it should scale, but it's worth a try, I think)

5 Replies

Sort By
  • Rob_Wilcox1's avatar
    Rob_Wilcox1
    Level 6
    11 years ago

    EVConverterSandbox is part of the 'indexing process', well in general terms it is (stuff goes through conversion so that it can be indexed).. so not specifically to do with EVPM or PST ingestion.

     

    Random idea .. good if you have a test environment :)

     

    Can you reproduce it in a test environment? If so.. what happens if you stop the indexing service?  All the items should get ingested, and there should be no crash/reboot. 

     

    After that, you could start the indexing service, and see how it handles processing the backlog?  Maybe pushing with EVPM is hitting it too hard (I mean this shouldn't happen, because it should scale, but it's worth a try, I think)

  • BlueBull's avatar
    BlueBull
    Level 4
    11 years ago

    I will give that a go. Thanks.

    I have tried to reproduce in my lab but I just do not have the data load from a production environment.

  • BlueBull's avatar
    BlueBull
    Level 4
    11 years ago

    Ok, I was unable to reproduce this issue in my lab. I then seup a batch of 515 PST files for ingestion with EVPM. I stopped the indexer service and started the ingestion. The ingestion completed 100% fine. I have now started the Indexer to catch up on the back-log and will report back soon.

    How can we troubleshoot the indexer and try and sort out the reboot issue?

  • BlueBull's avatar
    BlueBull
    Level 4
    11 years ago

    Just to give you another update. The Server config is as follows:

    • VM
    • 16 Cores
    • 32GB memory

    I have started the indexer now to cleanup the backlog. The machine is running at 100% CPU utilization and 95% memory. I noticed the slow increase when I was running the ingestion and indexing at the same time.

    Currently only indexing is running. No archival. Is this normal?

  • Rob_Wilcox1's avatar
    Rob_Wilcox1
    Level 6
    11 years ago

    Archiving will only run when archiving is scheduled, right?

    If you've ingested all of the PSTs, and indexing is now running flat out to index those items which were ingested then that it is likely to take a while.

     

    I would suggest:

    - If this works, and doesn't cause the crash. Maybe there is either an issue with the mix of PST ingest and Indexing at the same time, eg load, or data-content

    - If this still causes a crash, then the issue is more likely something to do with the data

     

    Either way around you'll need to get through to Backline or 'beyond' inside Symantec for assistance in figuring out what is tripping up the indexing engine.  NOTHING should be able to blue screen a machine, so you might also need to get involvement from Microsoft to capture dumps and have them analysed.