Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • MetaGer MetaGer
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 64
    • Issues 64
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 11
    • Merge requests 11
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • open-source
  • MetaGerMetaGer
  • Issues
  • #116

Closed
Open
Created Jul 08, 2016 by Dominik Hebeler@dominikOwner

Der Status der laufenden Worker wird noch nicht in die Suche mit einbezogen.

Wir haben auf gut Glück auf unseren Servern 100 Worker Prozesse am laufen. Eine Suche mit 20 Suchmaschinen würde 20 davon in Beschlag nehmen. Das bedeutet also, dass parallel maximal 5 solcher Prozesse laufen dürften, damit es nicht zu Verzögerungen bzw sogar fehlenden Ergebnissen kommen würde.

Idee wäre folgende Logik bevor eine Suche gestartet wird:

  • Aktuellen Queue Status überprüfen
    • Besorgen der aktuellen Anzahl laufender Worker
    • Besorgen der aktuellen Länge der Warteschlange
    • Anzahl der benötigten Jobs Zwischenspeichern.
    • Berechne aus diesen Daten, ob die Suche überhaupt sofort ausgeführt werden kann.
    • Schreibe diese Werte in eine Log-Datei, damit wir einen Monitor entwickeln können.
  • Solange der Job nicht ausgeführt werden kann
  • Update für die aktuelle Länge der Warteschlange
  • Sleep
Assignee
Assign to
Time tracking