PassMark Logo
Home » Forum

Announcement

Collapse
No announcement yet.

Indexer concurrency limit?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Indexer concurrency limit?

    My company has recently been having an issue which I can't find any mention of in the forum or documentation. I think I've discovered the cause and fix for it, but I was curious (a) if anyone else has encountered this issue; (b) if this was intentional in the design or if it's more bug-like, and; (c) if an upgrade to Zoom might offer us a better solution.

    Beginning some time in March, I found that some of our nightly Zoom scheduled tasks were failing. We have 12 or so tasks, for different websites, and this issue seemed to be happening to a handful of them, but generally not with any consistency or regularity. The problem -- without fail -- was that the .zcfg files were corrupted, and it appeared that happened when the scheduled task started. Trying to run or save the configuration gave the message "No indexing option selected. You have disabled all indexing options. You must select at least one or more indexing options for Zoom to index your website." Since it is impossible to create a file like this through the UI, there had to be some automated process doing it.

    At first I thought it might have been the server file synchronization, but this kept happening even after that was turned off. Through assorted testing (and luck) I found that only TWO instances of the Indexer could be running at the same time. If two indexing jobs were already running and I started a third one, it would immediately throw an error in the Application Event Log and write out a bad .zcfg file. Since some of the sites being indexed have somewhat long running jobs (2-3 hours in some cases), this 2-Indexer limit was being hit often, especially after two additional sites were added this spring.

    Is this something anyone else has encountered? Can anyone confirm that there is a limit on the number of running Indexer instances? Is this an aspect of the program itself, or can server circumstances bring this about (e.g., limited available memory)? If this situation is unavoidable, is there any way to prevent the error from corrupting the configuration file? (THAT was a very annoying part in this.) We're currently running 7.1.1003 (Pro); would later builds of 7.1 or the new version provide different results -- either by not having an application limit or by maintaining the settings of the configuration?

    For the time-being, I've rearranged the schedule of the tasks so that only two jobs would ever be running at one time (outside of extraordinary circumstances). It works, but it's not a perfect solution, as not all the indexing tasks are done before "business hours" kick in for some sites, and there's a great possibility of negative interaction with some other nightly tasks (such as database backups or maintenance).

    If anyone has any insights or suggestions, that would be most appreciated.

  • #2
    Can anyone confirm that there is a limit on the number of running Indexer instances?
    There is no fixed limit.
    But eventually you'll run out of RAM, or disk space, or some other resource.
    But you need to make sure that the different indexing sessions are using different configuration files and different output folders.

    it would immediately throw an error in the Application Event Log
    What exactly was the error?
    If we can know the exact error there is a better chance that we can say if it is a bug that is already fixed or not.

    Comment


    • #3
      There is no fixed limit.
      But eventually you'll run out of RAM, or disk space, or some other resource.
      But you need to make sure that the different indexing sessions are using different configuration files and different output folders.
      They're most definitely using different configurations -- different configs, different folders, completely different sites. I started a couple tasks to see what sort of process impact there was: CPU was 8-12% higher (leaving ~80% CPU for use) and memory moved from 72% to 74%. Not any apparent drain, but this was outside of the normal run times, so I'll need to look into any other processes that might be running at the schedule job times. (It's a clustered node of a small web server farm; I'd be surprised if there was anything that intensive going on overnight.)


      What exactly was the error?
      If we can know the exact error there is a better chance that we can say if it is a bug that is already fixed or not.
      The error itself seems fairly generic, but perhaps your familiarity with the underlying code would give it more meaning. The only difference I've seen is the exception code -- 0xc0000409 or 0xc0000005. I haven't see any obvious pattern for the exception codes, but I also haven't really looked for one.


      Log Name: Application
      Source: Application Error
      Event ID: 1000
      Level: Error
      User: N/A
      OpCode:
      Logged: SEE BELOW
      Task Category: (100)
      Keywords: Classic
      Computer:

      (5/8/2019 08:31:04 AM)
      Faulting application name: ZoomIndexer.exe, version: 7.1.1003.0, time stamp: 0x57510910
      Faulting module name: ZoomIndexer.exe, version: 7.1.1003.0, time stamp: 0x57510910
      Exception code: 0xc0000409
      Fault offset: 0x001a6299
      Faulting process id: 0x8f10
      Faulting application start time: 0x01d505b30b9ac6ef
      Faulting application path: C:\Program Files (x86)\Zoom Search Engine 7.0\ZoomIndexer.exe
      Faulting module path: C:\Program Files (x86)\Zoom Search Engine 7.0\ZoomIndexer.exe
      Report Id: 4a6329c6-71a6-11e9-80f0-f01fafe5cb7e
      Faulting package full name:
      Faulting package-relative application ID:

      (5/8/2019 08:31:32 AM)
      Faulting application name: ZoomIndexer.exe, version: 7.1.1003.0, time stamp: 0x57510910
      Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
      Exception code: 0xc0000005
      Fault offset: 0x03379710
      Faulting process id: 0x4458
      Faulting application start time: 0x01d505b31bfe1513
      Faulting application path: C:\Program Files (x86)\Zoom Search Engine 7.0\ZoomIndexer.exe
      Faulting module path: unknown
      Report Id: 5add12bb-71a6-11e9-80f0-f01fafe5cb7e
      Faulting package full name:
      Faulting package-relative application ID:

      Comment


      • #4
        Both of these events (Exception code: 0xc0000409 & Exception code: 0xc0000005) indicate that the software has crashed.

        You are running release 7.1.1003 from June 2016.

        There have been dozens of bug fixes and improvements in the last 3 years. See,
        https://www.zoomsearchengine.com/zoom/whatsnew.html
        https://www.zoomsearchengine.com/zoo...n7history.html

        So first step in debugging it to get to a newer software release. Either V8, or at least the final V7 patch release.

        Comment

        Working...
        X