Gespräch:Semantik MW Cronjob Optimierung

Über diese Seite Gespräch

Semantik MW Cronjob Optimierung
ChatGPT Sophos GPT-4
19. März 2025 n. Chr. erst.
Ausgabe 00
Ausgabe 00
unüberarbeitet ungeprüft
keine Datei

Wir haben Semantik MediaWiki auf Mac mini M1 installiert.

Nun möchte ich crontab für maintenance php Sckripte erstellen, damit über nach vergleichsweise "php maintenance/run.php runJobs --maxjobs=10000" wiederholt läuft, bis die runJobs vollständig erledigt wurden. Die Begrenzung auf 1000 beruht auf der Erkenntnis, daß bei mehr als 10000 runJob manchmal hängenbleibt und so runJob's unerledigt verbleiben. Eventuell liegt dies an einer RAM oder Cache Begrenzung, die man vielleicht vorab beheben sollte, sodaß man auf die 10000 Beschränkung verzichten kann.

Was schlägst du als IT-Spezialist in Sachen Semantik MediaWiki vor, wie dies zu lösen ist und welche maintenance Skripte als crontab auszuführen sind?

Sophos:

Überlegt zu crontab und MediaWiki-Wartung für 40 Sekunden

Lösen von Crontab-Problemen
Die Frage betrifft die Konfiguration eines Cronjobs für die Wartung von Semantic MediaWiki auf einem Mac mini M1. Es scheint, dass das Skript php maintenance/run.php runJobs --maxjobs=10000 regelmäßig ausgeführt werden soll, aber bei mehr als 10000 Jobs Probleme auftreten. Vielleicht liegt das an einer RAM- oder Cache-Begrenzung. Als Lösung könnte man versuchen, diese Systemressourcen zu erhöhen. Ein sinnvoller Ansatz könnte sein, die Maximaljobzahl schrittweise zu optimieren und risikofrei zu erhöhen, während die Systemauslastung im Blick behalten wird.
Lösen von Crontab-Problemen
Der Benutzer möchte ein Crontab für Wartungsskripte erstellen, bei dem das Skript php maintenance/run.php runJobs --maxjobs=10000 regelmäßig ausgeführt wird, jedoch bei mehr als 1000 Jobs ein Problem auftritt. Daher vermutet der Benutzer eine RAM- oder Cache-Begrenzung als Ursache, die zu den Problemen führt. Ein möglicher Lösungsansatz wäre, die Systemressourcen zu optimieren, um die Anzahl der maximalen Jobs zu erhöhen, ohne dass das Skript hängen bleibt. Wichtig ist, auch die Crontab-Einstellungen regelmäßig zu überwachen, um Abbrüche zu vermeiden.
Lösen von Cron und Wartungsjobs
Der Benutzer möchte die runJobs-Wartung regelmäßig ausführen, aber es gibt eine Hangsituation bei mehr als 10000 Jobs. Ich denke, anstelle eines festen Limits von 1000 Jobs, könnte ein Shell-Skript mit einer Schleife sinnvoll sein, das runJobs immer wieder aufruft, bis keine Jobs mehr übrig sind. Wenn RAM- oder Caching-Probleme vermutet werden, könnte PHPs memory_limit in php.ini angepasst oder der --memory-limit-Schalter genutzt werden. Ein Beispiel-Cron-Job wäre:

Hier einige Empfehlungen, wie Du den Job-Queue-Prozess robuster und ressourcenschonender gestalten kannst:

1. Batch-Verarbeitung in kleineren Schritten

Anstatt einen großen Befehl mit 10.000 Jobs zu starten – was offenbar zu Hängern führen kann – empfiehlt es sich, kleinere Job-Batches (z. B. 1.000 Jobs) zu verarbeiten. Dadurch werden PHP und das System nicht mit zu vielen Jobs gleichzeitig belastet. Dies kannst Du in der crontab so umsetzen, dass der Befehl regelmäßig (z. B. jede Minute) ausgeführt wird:

bash

Kopieren

* * * * * /usr/bin/php /pfad/zu/deinem/wiki/maintenance/run.php runJobs --maxjobs=1000 >> /pfad/zu/deinem/wiki/logs/runjobs.log 2>&1

So wird – sofern noch Jobs vorhanden sind – immer wieder ein Batch abgearbeitet.

2. Anpassung der PHP-Konfiguration

Falls Speicher- oder Cache-Limitationen die Ursache sind, solltest Du folgende Punkte prüfen:

memory_limit erhöhen: Stelle sicher, dass in Deiner PHP-CLI-Konfiguration ein ausreichend hoher Speicherlimit-Wert (z. B. 512M oder mehr) gesetzt ist. Du kannst dies direkt im Cronjob überschreiben, z. B.: bash Kopieren /usr/bin/php -d memory_limit=512M /pfad/zu/deinem/wiki/maintenance/run.php runJobs --maxjobs=1000
Cache-Einstellungen: Prüfe, ob eventuell verwendete Caching-Mechanismen (z. B. APCu, memcached) ausreichend konfiguriert sind und genügend Ressourcen erhalten.

3. Wiederholte Ausführung bis zum Abschluss

Wenn Du sicherstellen möchtest, dass die Jobs vollständig abgearbeitet werden, kannst Du alternativ ein Wrapper-Skript erstellen, das den Job-Queue-Prozess so lange wiederholt, bis keine Jobs mehr vorhanden sind. Ein einfaches Bash-Skript könnte folgendermaßen aussehen:

bash

Kopieren

#!/bin/bash

while /usr/bin/php -d memory_limit=512M /pfad/zu/deinem/wiki/maintenance/run.php runJobs --maxjobs=1000 | grep -q "job"; do

sleep 5

done

Dieses Skript führt den Befehl in einer Schleife aus, überprüft (z. B. anhand eines spezifischen Texts in der Ausgabe), ob noch Jobs vorhanden sind, und pausiert zwischen den Durchläufen. (Passe den Suchbegriff „job“ an, je nachdem, welche Ausgabe im Erfolgsfall erzeugt wird.)

4. Weitere Wartungsskripte

Neben dem regelmäßigen Ausführen von runJobs können folgende Maintenance-Skripte sinnvoll sein:

update.php: Führt notwendige Aktualisierungen der Datenbankstruktur und anderer Systemkomponenten durch. Empfohlener Cronjob (evtl. nachts oder zu Zeiten geringer Last): bash Kopieren 0 3 * * * /usr/bin/php /pfad/zu/deinem/wiki/maintenance/update.php >> /pfad/zu/deinem/wiki/logs/update.log 2>&1
rebuildRecentChange.php: Falls es Probleme mit den „Letzten Änderungen“ gibt, kann dieses Skript helfen, die entsprechenden Tabellen zu bereinigen.
cleanUploads.php: Falls Uploads verwaltet werden, hilft dieses Skript dabei, ungenutzte Dateien zu entfernen.

Wähle die Skripte, die in Deinem Setup notwendig sind und sorge dafür, dass sie zu Zeiten niedriger Last ausgeführt werden.

Zusammenfassung

Batchweise Verarbeitung: Nutze kleinere Batches (z. B. 1000 Jobs) in der crontab und rufe runJobs regelmäßig auf.
PHP-Ressourcen: Erhöhe den PHP memory_limit und prüfe Cache-Konfigurationen.
Wiederholungsschleife: Alternativ kann ein Wrapper-Skript verwendet werden, das so lange läuft, bis alle Jobs erledigt sind.
Weitere Wartung: Ergänze Deinen Cronjob mit anderen wichtigen Maintenance-Skripten wie update.php, um die Systemintegrität zu wahren.

Diese Maßnahmen sollten dazu beitragen, dass die Job-Verarbeitung stabiler läuft und dass Hänger vermieden werden.

Nikolaos:

Ich würde memory_limit=512M lieber in der entsprechenden Konfigurationsdatei (php.ini) allegemin fest zuweisen und nicht jedes Mal setzen.

Für Semantik MediaWiki (SMW) gibt es cron jobs, die mindestens alle 90 Tage ausgeführt werden sollen, und SMW rein und funktional zu halten. Erkundige dich bitte nach diesen regelmäßigen zauszuführenden Skripten und gebe entsprechende Vorschläge aus.

Sophos:

Razoniert über Wartungsskripte für SMW für 44 Sekunden

Verstehen der Anfrage
Der Benutzer möchte das memory_limit=512M dauerhaft in der php.ini festlegen und nicht jedes Mal manuell setzen. Außerdem geht es um die regelmäßige Ausführung von Cron-Jobs für Semantic MediaWiki (SMW), um es sauber und funktional zu halten, mindestens alle 90 Tage. Ich muss herausfinden, welche Cron-Jobs hier nötig sind, und dem Benutzer passende Vorschläge machen.
Okay, ich werde diesen Zusammenhang weiter durchdenken und passende Informationen zur Konfiguration und den Cron-Jobs bereitstellen.
Über Wartungsskripte für SMW
Die Frage bezieht sich darauf, welche Wartungsskripte regelmäßig in SMW ausgeführt werden sollten, um das System sauber und funktional zu halten, mindestens alle 90 Tage. In Semantic MediaWiki gibt es mehrere empfohlene Skripte, wie z.B. „rebuildData.php“, „updateData.php“ und „smwMergeData.php“, die für die Neuindizierung und das Bereinigen des Systems wichtig sind. Auch „rebuildSearchIndex.php“ und „cleanupJobs.php“ könnten regelmäßig ausgeführt werden, um den Betrieb zu optimieren und Fehler zu vermeiden.
Über Wartungsskripte für SMW
In SMW scheint „rebuildData.php“ ein wesentliches Wartungsskript zu sein, das regelmäßig ausgeführt werden sollte, insbesondere bei umfangreichen semantischen Abfragen. Weitere wichtige Skripte sind „runJobs“, das automatisch den Index aktualisiert, und „cleanupJobs.php“, um nicht mehr benötigte Daten zu bereinigen. Auch „updateData.php“ und „rebuildLinks.php“ könnte man in Betracht ziehen. Es wird empfohlen, „rebuildData.php“ einmal im Quartal oder alle 90 Tage auszuführen, um das System sauber und funktional zu halten.
Wartungsskripte für SMW
Basierend auf den Recherchen, hier eine Liste an empfohlenen Cronjobs für die regelmäßige Wartung von SMW (mindestens alle 90 Tage):

runJobs: Sollte regelmäßig (mindestens alle Minute) ausgeführt werden, um laufende Aufgaben zu verarbeiten.
rebuildData.php: Einmal alle 90 Tage ausführen, um den semantischen Index neu zu erstellen und Inkonsistenzen zu vermeiden.
updateData.php: Falls verwendet, für inkrementelle Updates der semantischen Daten.
update.php: Für allgemeine Wartungsarbeiten bei Datenbankänderungen, z.B. monatlich.

Der Befehl für "rebuildData.php" könnte so aussehen:

Und das memory_limit sollte dauerhaft in der php.ini definiert werden.

Basierend auf den Empfehlungen der Semantic MediaWiki‑Dokumentation und Best Practices solltest Du neben dem kontinuierlichen Abarbeiten der MediaWiki‑Jobs (über „runJobs“) folgende SMW-spezifische Wartungsskripte in regelmäßigen Abständen (mindestens alle 90 Tage) einplanen:

1. rebuildData.php

Zweck:

Dieses Skript erstellt den gesamten semantischen Index neu und behebt so Inkonsistenzen oder veraltete Daten, die sich im Laufe der Zeit ansammeln können. Gerade bei umfangreichen Wikis oder häufigen Änderungen ist ein periodischer Rebuild sinnvoll, um die Datenintegrität und Performance sicherzustellen.

Empfohlene Ausführung:

Alle 90 Tage (oder – je nach Größe und Aktivität des Wikis – auch öfter, wenn Probleme auftreten).

Beispiel-Cronjob:

bash

Kopieren

0 2 1 */3 * /usr/bin/php /pfad/zu/deinem/wiki/maintenance/rebuildData.php >> /pfad/zu/deinem/wiki/logs/rebuildData.log 2>&1

Dieser Cronjob startet am 1. Tag jedes dritten Monats um 02:00 Uhr.

2. updateData.php (falls verwendet)

Zweck:

Das Skript „updateData.php“ aktualisiert inkrementell die semantischen Daten der Seiten, die seit dem letzten Update verändert wurden.

Hinweis: In vielen Setups wird – wenn der Job-Queue-Mechanismus korrekt arbeitet – primär über „runJobs“ der Großteil der Aktualisierungen abgewickelt. Dennoch kann ein regelmäßiger, separater Aufruf von updateData.php sinnvoll sein, um sicherzustellen, dass alle semantischen Beziehungen aktuell sind.

Empfohlene Ausführung:

Je nach Aktivität des Wikis kann es sinnvoll sein, dieses Skript in einem längeren Intervall (z. B. monatlich oder vierteljährlich) zusätzlich zum automatischen Job-Processing laufen zu lassen.

Beispiel-Cronjob (optional):

bash

Kopieren

0 3 1 */3 * /usr/bin/php /pfad/zu/deinem/wiki/maintenance/updateData.php >> /pfad/zu/deinem/wiki/logs/updateData.log 2>&1

3. Allgemeine MediaWiki-Maintenance (update.php etc.)

Zweck:

Neben den SMW-spezifischen Skripten sollte auch die allgemeine Wartung des Wikis nicht vernachlässigt werden. Das Skript „update.php“ etwa führt notwendige Datenbank- und Konfigurationsanpassungen durch, falls Änderungen an der MediaWiki-Version oder -Struktur vorgenommen wurden.

Empfohlene Ausführung:

Dieses Skript wird typischerweise nicht so häufig benötigt wie die SMW‑Skripte. Eine regelmäßige (z. B. monatliche oder vierteljährliche) Ausführung kann hier je nach Update- und Änderungsrhythmus sinnvoll sein.

Beispiel-Cronjob:

bash

Kopieren

0 4 * * 0 /usr/bin/php /pfad/zu/deinem/wiki/maintenance/update.php >> /pfad/zu/deinem/wiki/logs/update.log 2>&1

Dies würde das Skript jeden Sonntag um 04:00 Uhr ausführen.

4. Hinweise zur PHP-Konfiguration

Da Du das memory_limit=512M lieber dauerhaft in der php.ini festlegst, entfällt der zusätzliche Parameter beim Aufruf der Skripte. Stelle aber sicher, dass die CLI-Konfiguration von PHP (für Cronjobs) ebenfalls den gewünschten Wert verwendet. Überprüfe dazu die CLI-spezifische php.ini oder setze den Wert global.

Zusammenfassung

rebuildData.php: Führe diesen Befehl mindestens alle 90 Tage aus, um den semantischen Index vollständig neu aufzubauen und Inkonsistenzen zu beheben.
updateData.php: Optional als ergänzende Maßnahme zur inkrementellen Aktualisierung, ebenfalls in regelmäßigen Intervallen (z. B. 90 Tage oder monatlich) einplanen.
update.php: Allgemeine MediaWiki-Wartung, je nach Bedarf in einem längerfristigen Intervall (z. B. monatlich oder vierteljährlich) ausführen.
PHP-Konfiguration: Setze memory_limit=512M dauerhaft in der php.ini, sodass die Skripte ohne zusätzlichen Parameter arbeiten können.

Diese regelmäßigen Cronjobs helfen, Semantic MediaWiki stabil, aktuell und performant zu halten. Die konkreten Intervalle können je nach Größe und Aktivität Deines Wikis angepasst werden.

Nikolaos:

Danke für deine Ausarbeitung. Ich werde erstmal die Scripte manuell bei Bedarf ausführen, solange ich noch beim Einrichten von SMW bin.

Sophos:

Razoniert über SMW-Wartung und Cronjobs für 8 Sekunden

Acknowledging the user's message
Okay, the user is thanking me for the details! I’ll just acknowledge with something simple like “You're welcome" (or in German), and offer further help if needed. They mentioned manually running the scripts while setting up SMW, so maybe I’ll add something like, “If you need any more assistance, feel free to reach out.” It’s important to be available for any questions. I’ll finalize it in German as the conversation is in German: “Gern geschehen! Bei weiteren Fragen stehe ich dir zur Verfügung.”

Freut mich, dass die Ausarbeitung hilfreich war! Falls du weitere Fragen hast oder Unterstützung bei der Einrichtung benötigst, stehe ich gerne zur Verfügung. Viel Erfolg mit SMW!

Nikolaos:

Ich habe zum Test eine neue Seite mit einem unserer Chat's als Inhalt angelegt. Anschließend habe ich nach genau einem Satz mittels "…Satz…" gesucht und es wurde keine Übereinstimmung und auch nicht die Seite gefunden, die diesen Satz enthält. Ich habe dann "php maintenance/run.php runJobs" ausgeführt. Im Anschluß daran wurde dann der Satz und die Seite gefunden. Ich habe vier Seiten geändert und oder angelegt und es wurden 4 Jobs gefunden, die durch "php maintenance/run.php runJobs" erledigt wurden.

Derzeitiger Stand ist offenbar, daß die Veränderung und das Anlegen von Seiten zu erledigende Jobs einträgt, diese jedoch nicht automatisch erledigt werden, sondern das Script "php maintenance/run.php runJobs" zu deren Erledigung manuell ausgelöst werden muß.

Wie kann ich erreichen, daß die Funktion des Update des ElasticSearch-Index und er SMW Tripels durch das Speichern der Seite so ausgelöst wird, daß sich keine zu erledigen Jobs ansammeln? Würde ich es so belassen, würde ich mittels der Suche immer erst dann etwas finden, wenn ich zuvor "php maintenance/run.php runJobs" ausgeführt habe.

Sophos:

Nachgedacht für 40 Sekunden

Beheben des Job-Auslösens
Es scheint, dass beim Erstellen und Bearbeiten von Seiten Jobs ausgelöst werden, die jedoch nicht automatisch abgeschlossen werden. Das Skript "php maintenance/run.php runJobs" muss manuell ausgeführt werden, um diese Jobs zu erledigen. Um sicherzustellen, dass der ElasticSearch-Index und die SMW Tripels automatisch beim Speichern der Seite aktualisiert werden, könnten Sie die Cron-Jobs oder einen anderen automatisierten Mechanismus einrichten, der diese Aufgaben im Hintergrund ausführt, ohne dass Sie das Skript manuell auslösen müssen.
Automatisierung der Job-Verarbeitung
Das aktuelle Problem ist, dass das Update des ElasticSearch-Index und der SMW Triples nur erfolgt, wenn "php maintenance/run.php runJobs" manuell ausgeführt wird. Das liegt daran, dass MediaWiki Job-Warteschlangen verwendet, die nach Bedarf verarbeitet werden, oft durch Cron-Jobs oder asynchrone Methoden. Um das zu automatisieren, könnte man eine Erweiterung oder ein entsprechendes Skript einsetzen, das die Jobs direkt nach dem Speichern der Seite automatisch auslöst, sodass keine Jobs mehr im Hintergrund ansammeln.
Automatisches Ausführen der Jobs
Die Lösung, um die Jobs nach dem Speichern der Seite sofort auszuführen, besteht darin, den Wert von $wgJobRunRate in der LocalSettings.php auf 1 zu setzen. Dadurch wird sichergestellt, dass die Job-Warteschlange nach jedem Seitenaufruf verarbeitet wird und der ElasticSearch-Index sowie die SMW-Triple direkt aktualisiert werden. Allerdings ist zu beachten, dass dies die Ladezeit der Seite verlängern könnte. Alternativ können Erweiterungen wie „RunJobsOnPageLoad“ oder „QueueRunner“ verwendet werden.

MediaWiki verarbeitet Änderungen standardmäßig asynchron, um die Performance beim Speichern und Anzeigen von Seiten nicht zu beeinträchtigen – deswegen werden die Jobs zunächst in die Queue eingereiht. Wenn du möchtest, dass der ElasticSearch-Index und die SMW‑Tripel sofort aktualisiert werden, gibt es zwei grundsätzlich mögliche Ansätze:

1. Job-Queue synchron abarbeiten

Option A: Den Job-Queue-Backend auf „sync“ setzen

Du kannst in deiner LocalSettings.php die Job-Queue so konfigurieren, dass alle Jobs synchron (d. h. unmittelbar) abgearbeitet werden. Dies erreichst du, indem du folgende Zeile hinzufügst:

php

Kopieren

$wgJobQueueBackend = 'sync';

Dadurch werden Jobs sofort während des Seiten-Speichervorgangs verarbeitet, sodass der ElasticSearch-Index und die SMW‑Tripel sofort aktualisiert werden. Beachte, dass diese Methode vor allem für Entwicklungs- oder kleinere Wikis sinnvoll ist, da sie zu längeren Ladezeiten führen kann, wenn viele Jobs anfallen.

2. Job-Ausführungsrate erhöhen

Option B: Erhöhung von $wgJobRunRate

Alternativ kannst du die Wahrscheinlichkeit, dass bei einem Seitenaufruf (oder direkt nach dem Speichern) ein Job abgearbeitet wird, erhöhen. Standardmäßig wird nur ein Bruchteil der anstehenden Jobs pro Seitenaufruf bearbeitet. Setze in deiner LocalSettings.php den Parameter beispielsweise so:

php

Kopieren

$wgJobRunRate = 1.0;

Das bedeutet, dass bei jedem Aufruf die Job-Queue zu 100 % abgearbeitet wird. Auch hier gilt: Das kann zu einer spürbaren Verzögerung beim Speichern und Anzeigen der Seite führen, vor allem wenn viele Jobs anstehen.

Fazit

Synchron (Option A): Mit $wgJobQueueBackend = 'sync'; werden alle Jobs unmittelbar beim Speichern abgearbeitet, was den Suchindex und SMW‑Tripel sofort aktualisiert. Diese Methode ist gut für Tests und kleinere Installationen, aber potenziell performanceintensiv.
Erhöhte Job-Ausführungsrate (Option B): Mit $wgJobRunRate = 1.0; wird der Job-Queue-Mechanismus während des Seitenaufrufs aggressiver und verarbeitet alle Jobs, bevor die Seite vollständig geladen wird. Auch hier können längere Ladezeiten auftreten.

Wähle die Methode, die zu deinem Anwendungsfall und deiner Serverleistung passt. Für eine produktive Umgebung empfiehlt es sich meist, einen Kompromiss zu finden oder über einen regelmäßigen Cronjob (wie in vorherigen Beispielen beschrieben) die Queue außerhalb des Seitenaufrufs abzuarbeiten, um die Benutzererfahrung nicht negativ zu beeinflussen.

Falls du weitere Fragen hast oder Unterstützung bei der Konfiguration benötigst, helfe ich gerne weiter.

Nikolaos:

Danke. An sich wäre eine Idle-Bewertung besser, sodaß wenn keine Seitenaufrufe geschehen, SMW also untätig ist, der Job-Queue abgearbeitet wird. Gibt es eine derartige Option, die man in LocalSettings.php einrichten könnte?

2/2

Sophos:

Reasoned about idle-triggered job processing für 26 Sekunden

Erklärung zur Job-Warteschlange
Es gibt keine direkte Möglichkeit in MediaWiki, die Job-Warteschlange automatisch bei Inaktivität zu verarbeiten. Normalerweise wird die Warteschlange bei Seitenaufrufen verarbeitet, nicht wenn keine Aufrufe stattfinden. Eine Lösung wäre, einen Cron-Job einzurichten, um das manuell zu steuern, aber es gibt keinen eingebauten Mechanismus, der die Jobs bei serverseitiger Inaktivität automatisch ausführt. Die Warteschlangenbearbeitung läuft also meist durch Seitenanforderungen.
Über Job-Warteschlange und Inaktivität
In MediaWiki gibt es $wgJobRunRate, um die Anzahl der abgearbeiteten Jobs bei Seitenaufrufen festzulegen, aber keine eingebaute Funktion, die in Inaktivitätsphasen Jobs ausführt. Die Warteschlange wird normalerweise nur durch Seitenanfragen bearbeitet. Eine Lösung wäre, Cron-Jobs oder ein externes Skript zu verwenden, das die Jobs bei geringem Traffic abarbeitet. Eine Erweiterung wie der "Background Job Queue"-Runner könnte helfen, aber es scheint keine spezifische Funktion für idle Verarbeitungen zu geben.

MediaWiki und SMW bieten von Haus aus keine Einstellung in der LocalSettings.php, die den Job-Queue automatisch während Inaktivitätsphasen abarbeitet. Der Mechanismus zur Abarbeitung von Jobs ist standardmäßig an Seitenaufrufe gekoppelt – was bedeutet, dass ohne Benutzerzugriffe keine Jobs verarbeitet werden.

Hier zwei alternative Ansätze:

Cronjob oder Daemon: Die gängige Lösung besteht darin, einen externen Cronjob (oder einen daemon-basierten Ansatz) einzurichten, der in regelmäßigen Intervallen – idealerweise in Zeiten geringer Aktivität – das Skript maintenance/run.php runJobs ausführt. Das stellt sicher, dass auch bei Inaktivität alle anstehenden Jobs abgearbeitet werden.
Erhöhung des $wgJobRunRate: Durch Erhöhen des Parameters $wgJobRunRate in der LocalSettings.php (zum Beispiel auf 1.0) wird bei jedem Seitenaufruf versucht, möglichst viele Jobs abzuarbeiten. Dieser Ansatz greift aber nur, solange auch tatsächlich Seitenaufrufe erfolgen, und ersetzt keinen dedizierten Idle-Prozess.

Falls Du also einen "Idle-Modus" wünschst, in dem die Jobs abgearbeitet werden, wenn keine Seitenaufrufe stattfinden, empfiehlt sich die Implementierung eines externen Mechanismus (Cronjob oder Daemon), da MediaWiki keine eingebaute Option dafür bereitstellt.

Nikolaos:

Wenn der Mechanismus zur Abarbeitung von Jobs standardmäßig an Seitenaufrufe gekoppelt ist, dann besteht offenbar der Umstand, daß diese Funktion derzeit nicht funktioniert, da wenn dem so ist, die Beobachtung daß die Quelle-Jobs sich ansammeln aber nicht abgewickelt werden nicht sein kann. Also muß ich davon ausgehen, daß derzeit diese Funktion der automatisierten Abarbeitung durch Seitenaufruf nicht erfolgt – richtig? Wenn ja, woran könnte dies liegen?

Sophos:

Nachgedacht für 22 Sekunden

Überprüfung der Jobverarbeitung
Die Frage geht darum, dass die automatische Abarbeitung von Jobs an Seitenaufrufe gekoppelt ist, aber offenbar derzeit nicht funktioniert. Wenn dies der Fall ist, sollte sich die Quelle der Jobs nicht ansammeln, ohne abgewickelt zu werden. Also nehme ich an, diese Funktion läuft momentan nicht – richtig? Falls ja, könnte das Problem an einer Fehlkonfiguration im Mechanismus liegen, der vielleicht nicht richtig aufgerufen wird, oder es gibt ein Problem mit der Verbindung zwischen den Jobquellen und den Seitenaufrufen.
Ursachen der fehlerhaften Jobverarbeitung
Der Nutzer fragte sich, warum Jobs nicht bei Seitenaufrufen verarbeitet werden, sondern nur manuell über maintenance/run.php. Hier sind mögliche Ursachen:

Der Job-Queue verarbeitet möglicherweise keine asynchronen Jobs.
$wgJobRunRate könnte auf 0 gesetzt sein, was die Ausführung blockiert.
Probleme mit Lastverteilung oder Caching könnten die Verarbeitung stören.
Eine fehlende Seitenaktualisierung nach der Speicherung könnte ebenfalls das Problem sein.
Konflikte mit Hooks oder Erweiterungen könnten verantwortlich sein.
Unterschiedliche PHP-Versionen zwischen CLI und Webserver könnten ebenfalls eine Rolle spielen.

Es gibt noch viele weitere Aspekte zu prüfen!

Die automatische Abarbeitung der Job-Queue über Seitenaufrufe funktioniert grundsätzlich – allerdings gibt es mehrere Gründe, warum in deiner Umgebung die Jobs scheinbar nicht verarbeitet werden:

Caching oder Reverse-Proxy: Wenn Seiten häufig über einen Cache (zum Beispiel Varnish oder ein CDN) ausgeliefert werden, wird der PHP-Code (und damit auch die Job-Verarbeitung) oft gar nicht oder nur selten ausgeführt. In solchen Fällen sammeln sich Jobs an, weil die Seitenaufrufe nicht direkt über MediaWiki laufen.
Niedriger $wgJobRunRate-Wert: Der Parameter $wgJobRunRate bestimmt, welcher Anteil der anstehenden Jobs bei jedem Seitenaufruf abgearbeitet wird. Ist dieser Wert zu niedrig (zum Beispiel der Standardwert 0.1), werden nur sehr wenige Jobs pro Seitenaufruf verarbeitet. Dadurch kann es passieren, dass sich Jobs anhäufen – insbesondere bei wenig frequentierten Wikis. Eine Erhöhung dieses Wertes (z. B. auf 1.0) würde bewirken, dass bei jedem Seitenaufruf versucht wird, alle anstehenden Jobs abzuarbeiten, was aber auch zu längeren Ladezeiten führen kann.
Geringe Seitenaufrufe: In Test- oder Entwicklungsumgebungen, in denen nicht viele Seitenaufrufe stattfinden, wird die Job-Verarbeitung eben nicht häufig getriggert. Dadurch bleiben die Jobs in der Queue liegen, bis du sie manuell (oder per Cronjob) ausführst.
Fehlerhafte Job-Ausführung: Es kann auch vorkommen, dass ein oder mehrere Jobs fehlschlagen oder einen Fehler verursachen, der den weiteren Ablauf behindert. In diesem Fall werden eventuell nachfolgende Jobs nicht abgearbeitet. Ein Blick in die Error-Logs kann hier weiterhelfen, um zu erkennen, ob einzelne Jobs fehlerhaft sind.
Erweiterungen oder Konfigurationsprobleme: Falls Erweiterungen oder spezielle Konfigurationen (auch in Bezug auf ElasticSearch oder SMW-spezifische Jobs) vorhanden sind, die in den normalen Abarbeitungsprozess eingreifen, kann dies die automatische Verarbeitung behindern.

Kurz zusammengefasst:

Die automatische Abarbeitung über Seitenaufrufe funktioniert nur, wenn auch tatsächlich PHP-Code ausgeführt wird und genügend Ressourcen bzw. Aufrufe vorhanden sind – sowie wenn die Konfiguration (etwa der Wert von $wgJobRunRate) so eingestellt ist, dass ausreichend Jobs abgearbeitet werden. Sollten diese Voraussetzungen nicht gegeben sein, werden die Jobs nicht verarbeitet und sammeln sich in der Queue an.

Ein sinnvoller Ansatz ist daher oft, zusätzlich zu den automatischen Triggern durch Seitenaufrufe einen Cronjob einzurichten, der in regelmäßigen Intervallen maintenance/run.php runJobs ausführt, um sicherzustellen, dass alle Jobs auch bei geringer Aktivität abgearbeitet werden.

Nikolaos:

Ich habe nun "$wgJobRunRate = 0.1;" gesetzt, da bei 0.01 es 100 Seitenaufrufe geben muß bevor 1 Queue abgearbeitet wird. (Quelle: https://www.mediawiki.org/wiki/Manual:Job_queue). Habe ich das richtig verstanden?

Sophos:

Nachgedacht für 28 Sekunden

Überprüfung der JobQueue-Einstellung
Die Frage betrifft den Parameter $wgJobRunRate. Wenn dieser auf 0,1 gesetzt ist, sollten bei 0,01 tatsächlich 100 Seitenaufrufe nötig sein, bevor eine Warteschlangenaufgabe abgearbeitet wird. Laut der MediaWiki-Dokumentation steuert $wgJobRunRate, wie schnell die Warteschlange bei jeder Seitenanzeige verarbeitet wird. Der Wert 0,1 bedeutet, dass pro Seitenaufruf 10 % der Warteschlange abgearbeitet werden. Also ja, das hast du richtig verstanden.
Erklärung des Parameters $wgJobRunRate
Okay, also der Parameter $wgJobRunRate bestimmt, wie hoch die Wahrscheinlichkeit ist, dass bei jedem Seitenaufruf eine Aufgabe aus der Warteschlange verarbeitet wird. Ein Wert von 0,1 bedeutet, dass im Durchschnitt 1 von 10 Seitenaufrufen eine Aufgabe verarbeitet. Bei 0,01 dauert es im Durchschnitt 100 Seitenaufrufe, bevor eine Aufgabe verarbeitet wird. Wenn der Wert auf 1,0 gesetzt ist, wird bei jedem Aufruf alle Warteschlangenaufgaben abgearbeitet. Das hast du richtig verstanden!

Ja, das hast du richtig verstanden. Der Parameter $wgJobRunRate steuert, wie viele Jobs im Durchschnitt bei einem Seitenaufruf abgearbeitet werden. Bei einem Wert von 0.01 wird statistisch gesehen etwa ein Job pro 100 Seitenaufrufe ausgeführt – bei 0.1 also etwa ein Job alle 10 Seitenaufrufe. Beachte aber, dass dies Durchschnittswerte sind und die tatsächliche Abarbeitung auch von anderen Faktoren wie der Serverlast oder Caching-Mechanismen abhängen kann.

Nikolaos:

So erhöhe ich lediglich die Wahrscheinlichkeit das im Verhältnis 1:10 nun die Warteschlange geleert wird, so genau wird es nicht sein. Das SMW wird derzeit nur von mir genutzt und da gibt es keine echten Performance Einbußen, selbst wenn ich den Wert 1:1, also 1 einsetzen würde.

Sophos:

Nachgedacht für 13 Sekunden

Überprüfung der Einschätzung
Die Aussage des Nutzers bedeutet, dass er die Wahrscheinlichkeit erhöht, dass die Warteschlange im Verhältnis 1:10 geleert wird, was jedoch nicht ganz genau ist. Der SMW wird derzeit nur von ihm genutzt, und selbst bei einer Einstellung von 1:1 gibt es keine merklichen Performance-Einbußen. Es scheint, dass der Nutzer nach Bestätigung sucht, ob diese Einschätzung korrekt ist oder nach einer Einschätzung sucht, aber es ist nicht ganz eindeutig, ob eine Frage gestellt wird.
Erklärung zu $wgJobRunRate
Richtig, mit $wgJobRunRate wird gesteuert, wie viele Jobs pro Seitenaufruf verarbeitet werden. Es handelt sich nicht um eine deterministische Zahl, sondern um einen statistischen Durchschnitt. Wenn du der einzige Nutzer bist, kannst du den Wert auf 1 setzen. Das bedeutet, dass bei jedem Seitenaufruf alle noch ausstehenden Jobs ausgeführt werden. Wenn deine Wiki-Seite klein ist und du der einzige Nutzer bist, wird es keine großen Performance-Probleme geben, es könnte aber bei vielen Jobs zu einer leicht langsameren Ladezeit kommen.

Genau – $wgJobRunRate ist ein probabilistischer Faktor, der im Durchschnitt bewirkt, dass bei einem Seitenaufruf eine bestimmte Anzahl an Jobs abgearbeitet wird. Bei einem Wert von 0.1 werden statistisch gesehen etwa 10 % der wartenden Jobs abgearbeitet, was bedeutet, dass die Chance pro Seitenaufruf besteht, dass ein Job ausgeführt wird. Diese Einstellung garantiert jedoch nicht eine exakte 1:10-Verarbeitung pro Aufruf, sondern wirkt sich als Durchschnittswert aus.

Da du SMW derzeit nur selbst nutzt, kannst du ohne Bedenken den Wert auf 1 setzen. Mit $wgJobRunRate = 1 wird dann bei jedem Seitenaufruf versucht, alle anstehenden Jobs abzuarbeiten, was in einer Umgebung mit geringem Traffic und wenigen gleichzeitigen Zugriffen kaum spürbare Performance-Einbußen verursachen sollte.

Kurz gesagt:

Bei 0.1 wird im Mittel etwa ein Job pro 10 Seitenaufrufen abgearbeitet, aber es handelt sich um einen Durchschnittswert.
Bei 1 wird versucht, alle Jobs bei jedem Aufruf abzuarbeiten.

Da du SMW als Einzelnutzer betreibst, ist der Einsatz von 1 vollkommen in Ordnung.

Nikolaos:

Danke. Ich teste die Performance und kümmere mich dann um weitere Maßnahmen, wie chronologische Updates.

Sophos:

Nachgedacht für 6 Sekunden

Formulating response in German
Ich starte jetzt mit der Antwort: „Gern geschehen. Viel Erfolg beim Testen der Performance. Falls du weitere Fragen hast oder Unterstützung bei den chronologischen Updates oder anderen Maßnahmen benötigst, stehe ich dir gerne zur Verfügung.“
Ich werde den Satz einfach und freundlich lassen, vielleicht ein bisschen motivierend für den Nutzer, ohne zu viele Informationen zu überladen. Einfluss der Entwickleranweisungen berücksichtigen. Okay, Antwort steht!

Das klingt nach einem guten Plan. Viel Erfolg bei den Performance-Tests – und falls du später weitere Fragen hast oder Unterstützung bei chronologischen Updates oder anderen Maßnahmen benötigst, stehe ich dir gerne zur Verfügung.