MediaWiki

Handbuch:Jobwarteschlange

This page is a translated version of the page Manual:Job queue and the translation is 99% complete.
Outdated translations are marked like this.
Languages:

2009 (MediaWiki 1.6) wurde die Job-Warteschlange eingeführt, um langlaufende Aufgaben asynchron durchzuführen. Sie wurde mit dem Ziel entwickelt, viele kleine Prozesse zu handhaben (Stapelverarbeitung).

Set up

Es empfiehlt sich, die Ausführung von Jobs komplett im Hintergrund über die Kommandozeile zu planen. Standardmäßig werden Jobs am Ende einer Webanforderung ausgeführt. Deaktivieren Sie dieses Standardverhalten, indem Sie $wgJobRunRate auf 0 setzen.

Die Funktion runJobs.php sollte unter dem gleichen Benutzer ausgeführt werden, unter dem auch der Webserver läuft, um die korrekte Einhaltung der erforderlichen Rechte für das Dateisystem zu garantieren, falls Jobs auf hochgeladene Dateien zugreifen.

Cron

Sie können cron verwenden, um die Jobs jede Stunde auszuführen. Fügen Sie Ihrer crontab-Datei Folgendes hinzu: 

0 * * * * /usr/bin/php /var/www/wiki/maintenance/runJobs.php --maxtime=3600 > /var/log/runJobs.log 2>&1

Die Verwendung von Cron macht den Einstieg einfach, kann aber dazu führen, dass E-Mail-Benachrichtigungen und kaskadierende Templates nur langsam reagieren (bis zu einer Stunde Wartezeit). Erwägen Sie deshalb einen der folgenden Ansätze, um einen kontinuierlichen Job-Runner einzurichten.

Dauereinsatz

Wenn Sie Shell-Zugriff und die Möglichkeit haben, Init-Skripte anzulegen, können Sie einen einfachen Dienst einrichten, der Jobs ausführt, sobald sie verfügbar sind, und sie außerdem ein wenig bremst, um zu verhindern, dass der Job-Runner die CPU-Ressourcen des Servers für sich in Anspruch nimmt:

Erstellen Sie ein Bash-Skript, zum Beispiel in /usr/local/bin/mwjobrunner:

Skript erstellen

#!/bin/bash
# Tragen Sie den MediaWiki-Installationspfad in die folgende Zeile ein
MW_INSTALL_PATH="/home/www/www.mywikisite.example/mediawiki"
RUN_JOBS="$MW_INSTALL_PATH/maintenance/runJobs.php --maxtime=3600"
echo Job Service startet...
# Nach dem Hochfahren des Servers eine Minute warten, um anderen Prozessen Zeit zum Starten zu geben
sleep 60
echo Gestartet.
while true; do
	# Job-Typen, die schnellstmöglich ausgeführt werden müssen, egal wie viele in der Warteschlange stehen
	# Diese Jobs sollten im Betrieb sehr "wenig" Leistung erfordern.
	php $RUN_JOBS --type="enotifNotify"
	# Für alles andere begrenzen Sie die Anzahl der Jobs für jeden Batch.
	# Mit dem Parameter --wait wird die Ausführung hier angehalten, bis neue Jobs hinzugefügt werden,
	# um zu vermeiden, dass die Programmschleife unnötig läuft.
	php $RUN_JOBS --wait --maxjobs=20
	# Einige Sekunden warten, damit die CPU noch andere Aufgaben erledigen kann, z.B. die Bearbeitung von Web-Anfragen usw.
	echo 10 Sekunden warten...
	sleep 10
done

Je nachdem, wie leistungsfähig der Server ist und welche Auslastung vorliegt, können Sie die Anzahl der in jedem Zyklus auszuführenden Jobs und die Anzahl der Sekunden, die in jedem Zyklus gewartet werden, anpassen.

Das Script ausführbar machen (chmod 755).

Dienst erstellen

Legen Sie bei Verwendung von systemd eine neue Service-Unit an, indem Sie die Datei /etc/systemd/system/mw-jobqueue.service erstellen. Den Parameter User so setzen, dass er dem Benutzer zugeordnet ist, der PHP auf Ihrem Webserver ausführt: 

[Unit]
Description=MediaWiki Job runner

[Service]
ExecStart=/usr/local/bin/mwjobrunner
Nice=10
ProtectSystem=full
User=php-fpm
OOMScoreAdjust=200
StandardOutput=journal

[Install]
WantedBy=multi-user.target

Den Service mit diesen Befehlen aktivieren und starten: 

sudo systemctl enable mw-jobqueue
sudo systemctl start mw-jobqueue
sudo systemctl status mw-jobqueue

Job-Erledigung bei Seitenaufrufen

Standardmäßig wird bei jedem Seitenaufruf ein Job aus der Job-Warteschlange genommen und ausgeführt. Die Anzahl der bearbeiteten Jobs kann mittels $wgJobRunRate konfiguriert werden. Das Setzen dieser Variable auf 1 führt zu einer Jobabarbeitung pro Seitenaufruf. 0 deaktiviert die Ausführung von Jobs bei Seitenaufrufen, dann sollte runJobs.php per Hand oder automatisiert periodisch ausgeführt werden.

MediaWiki Version:
≥ 1.23

Wenn diese Option aktiviert ist, werden Jobs ausgeführt, indem ein Socket geöffnet und eine interne HTTP-Anfrage an eine nicht gelistete Spezialseite gestellt wird: Special:RunJobs. Siehe auch den Abschnitt asynchron.

Problem mit der Leistung

Wenn die Belastung durch die Ausführung von Jobs bei jeder Webanfrage zu groß ist, Sie aber keine Jobs über die Befehlszeile ausführen dürfen, können Sie $wgJobRunRate auf eine Zahl zwischen 1 und 0 reduzieren. Werte zwischen 1 und 0 sorgen dafür, dass „durchschnittlich“ alle 1 / $wgJobRunRate Seitenaufrufe ein Job erledigt wird. 

$wgJobRunRate = 0.01;

Manuelle Bedienung

Es gibt auch eine Möglichkeit, die Job-Warteschlange manuell zu leeren, zum Beispiel nach dem Ändern eines Templates, das auf vielen Seiten vorhanden ist. Führen Sie einfach das Wartungsskript maintenance/runJobs.php aus. Zum Beispiel: 

/path-to-my-wiki/maintenance$ php ./runJobs.php

Abgebrochene Jobs

Ein Job kann aus verschiedenen Gründen fehlschlagen. Um zu verstehen, warum, musst du die zugehörige Protokolldatei einsehen.

Wenn ein Job 3 Mal fehlschlägt (wenn das System also so viele Versuche unternommen hat), gilt der Job als "aufgegeben" und wird nicht mehr ausgeführt.

Relevanter Quellcode:

https://doc.wikimedia.org/mediawiki-core/master/php/JobQueue_8php_source.html#l00085

Ein abgebrochener Job ist:

Geschichte

Asynchron

Die Konfigurationsvariable $wgRunJobsAsync wurde hinzugefügt, um die synchrone Ausführung von Jobs in Szenarien zu erzwingen, in denen eine interne HTTP-Anfrage zur Jobausführung nicht erwünscht ist.

Bei der asynchronen Ausführung von Jobs wird eine interne HTTP-Verbindung geöffnet, über die die Ausführung der Jobs abgewickelt wird, und der Inhalt der Seite wird sofort an den Client zurückgegeben, ohne dass auf den Abschluss des Jobs gewartet wird. Andernfalls wird der Job in demselben Prozess ausgeführt und der Kunde muss warten, bis der Job abgeschlossen ist. Wenn der Job nicht asynchron ausgeführt wird, wird ein schwerwiegender Fehler während der Jobausführung an den Client weitergegeben und das Laden der Seite abgebrochen.

Auch wenn $wgRunJobsAsync auf true gesetzt ist, fällt PHP auf die synchrone Jobausführung zurück, wenn es keinen Socket öffnen kann, um die interne HTTP-Anfrage zu stellen. Es gibt jedoch eine Reihe von Situationen, in denen diese interne Anfrage fehlschlägt und die Jobs nicht ausgeführt werden, ohne auf die synchrone Jobausführung zurückzugreifen. Ab MediaWiki 1.28.1 und 1.27.2 steht $wgRunJobsAsync jetzt standardmäßig auf false.

Aufgeschobene Updates

Mit dem Mechanismus der "aufgeschobenen Updates" kann die Ausführung von Code für das Ende der Anfrage geplant werden, nachdem alle Inhalte an den Browser gesendet wurden. Das ist ähnlich wie das Einreihen eines Auftrags in eine Warteschlange, nur dass er sofort ausgeführt wird und nicht erst in einigen Minuten/Stunden in der Zukunft.

DeferredUpdates wurde in MediaWiki 1.23 eingeführt und erhielt größere Änderungen in MediaWiki 1.27 und 1.28. Das Ziel dieses Mechanismus ist es, die Web-Antworten zu beschleunigen, indem weniger Arbeit erledigt wird, sowie einige Arbeiten zu priorisieren, die vorher ein Job waren, der so schnell wie möglich nach dem Ende der Antwort ausgeführt werden sollte.

Eine aufschiebbare Aktualisierung kann EnqueueableDataUpdate implementieren, damit sie auch als Job in die Warteschlange gestellt werden kann. Dies wird z.B. von RefreshSecondaryDataUpdate in Core verwendet. Wenn die Aktualisierung aus irgendeinem Grund fehlschlägt, stellt sich MediaWiki als Job in die Warteschlange und versucht es später erneut, um den fraglichen Vertrag zu erfüllen.

Änderungen in MediaWiki 1.22

In MediaWiki 1.22 wurde die Ausführung der Job-Warteschlange bei jeder Anfrage auf der Seite geändert (Gerrit change 59797), so dass der Job nicht mehr innerhalb desselben PHP-Prozesses ausgeführt wird, der die Seite rendert, sondern ein neuer PHP-Cli-Befehl erzeugt wird, der runJobs.php im Hintergrund ausführt. Es funktioniert nur, wenn $wgPhpCli auf einen tatsächlichen Pfad gesetzt oder der abgesicherte Modus ausgeschaltet ist, ansonsten wird die alte Methode verwendet.

Diese neue Ausführungsmethode könnte einige Probleme verursachen:

  • Wenn $wgPhpCli auf eine inkompatible Version von PHP gesetzt ist (z.B. eine veraltete Version), können Jobs nicht ausgeführt werden (behoben in 1.23).
  • PHP open_basedir-Beschränkungen sind in Kraft, und $wgPhpCli ist nicht erlaubt (task T62208, behoben in 1.23).
  • Leistung: Auch wenn die Jobwarteschlange leer ist, wird der neue PHP-Prozess trotzdem gestartet (task T62210, behoben in 1.23).
  • Manchmal hängt der PHP-Prozess, der gestartet wird, am Server oder nur am CLI-Prozess, weil die Deskriptoren stdout und stderr nicht richtig umgeleitet werden (task T60719, behoben in 1.22)
  • Es funktioniert nicht bei gemeinsam genutztem Code (Wikifarmen), weil es keine zusätzlichen erforderlichen Parameter an runJobs.php übergibt, um das Wiki zu identifizieren, das den Job ausführt (task T62698, behoben in 1.23)
  • Normale Shell-Limits wie $wgMaxShellMemory , $wgMaxShellTime , $wgMaxShellFileSize werden auf den Prozess runJobs.php angewandt, der im Hintergrund ausgeführt wird.

Es gibt keine Möglichkeit, zur alten Handhabung der Job-Warteschlange bei Anfragen zurückzukehren, außer z.B. $wgPhpCli auf false zu setzen, was andere Probleme verursachen kann (task T63387). Sie kann durch Setzen von $wgJobRunRate = 0; vollständig deaktiviert werden, doch die Jobs werden dann nicht mehr bei Seitenanfragen ausgeführt, und du musst runJobs.php explizit ausführen, um die anstehenden Jobs regelmäßig zu starten.

Änderungen in MediaWiki 1.23

In MediaWiki 1.23 wird die Ausführungsmethode von 1.22 aufgegeben und die Jobs werden ausgelöst, indem MediaWiki eine HTTP-Verbindung zu sich selbst herstellt.

Sie wurde zunächst als API-Einstiegspunkt (Gerrit change 113038) entworfen, später aber in die nicht gelistete Spezialseite Special:RunJobs (Gerrit change 118336) umgewandelt.

Damit werden zwar verschiedene Fehler aus Version 1.22 behoben, aber es müssen immer noch viele PHP-Klassen in einem neuen Prozess in den Speicher geladen werden, um einen Job auszuführen, und es wird eine neue HTTP-Anfrage gestellt, die der Server bearbeiten muss.

Änderungen in MediaWiki 1.27

In MediaWiki 1.25 und MediaWiki 1.26 führte die Verwendung von $wgRunJobsAsync manchmal dazu, dass Jobs nicht ausgeführt wurden, wenn das Wiki eine benutzerdefinierte $wgServerName -Konfiguration hatte. Dies wurde in MediaWiki 1.27 behoben. task T107290

Änderungen in MediaWiki 1.28

Zwischen MediaWiki 1.23 und MediaWiki 1.27 führte die Verwendung von $wgRunJobsAsync dazu, dass Jobs nicht ausgeführt wurden, wenn MediaWiki Anfragen für einen Servernamen oder ein Protokoll stellte, das nicht mit dem aktuell konfigurierten Servernamen übereinstimmte (z.B. wenn sowohl HTTP als auch HTTPS unterstützt wird oder wenn MediaWiki hinter einem Reverse Proxy liegt, der zu HTTPS weiterleitet). Dies wurde in MediaWiki 1.28 behoben. task T68485

Änderungen in MediaWiki 1.29

Wenn $wgJobRunRate in MediaWiki 1.27.0 bis 1.27.3 und 1.28.0 bis 1.28.2 auf einen Wert größer als 0 gesetzt wird, kann ein Fehler wie der folgende in den Fehlerprotokollen oder auf der Seite erscheinen: 

PHP Notice: JobQueueGroup::__destruct: 1 buffered job(s) never inserted

Als Folge dieses Fehlers können bestimmte Updates in manchen Fällen fehlschlagen, z.B. werden die Mitglieder der Kategorien auf den Kategorieseiten nicht aktualisiert, oder die letzten Änderungen zeigen die Bearbeitung gelöschter Seiten an - selbst wenn du runJobs.php manuell ausführst, um die Jobwarteschlange zu leeren. Er wurde als Fehler (task T100085) gemeldet und in 1.27.4 und 1.28.3 behoben.

Jobbeispiele

Aktualisierung der Linktabellen nach Vorlagenänderungen

Wird im Wiki eine Vorlage bearbeitet, fügt MediaWiki für jede Seite, die diese Vorlage verwendet, einen Job der Jobwarteschlange hinzu. Jeder Job ist dabei der Befehl, die entsprechende Seite aufzurufen, die Vorlage neu zu expandieren und die Linktabelle entsprechend zu aktualisieren. Zuvor blieben die Host-Artikel so lange veraltet, bis entweder ihr Parser-Cache ablief oder ein/e Benutzer/in den Artikel bearbeitete.

Außerkraftsetzen des HTML-Caches

Weitere Vorgänge können darüberhinaus für eine große Seitenanzahl zum Ungültigwerden des jeweiligen HTML-Caches führen:

  • Änderung eines Bildes (alle Vorschaubilder, die „Thumbnails“, müssen neu gerendert und ihre Größen neu berechnet werden)
  • Löschung einer Seite (alle Links auf anderen Seiten müssen von blau nach rot geändert werden)
  • Neuanlage oder Wiederherstellung einer Seite (wie vorstehend, aber von rot nach blau)
  • Änderung einer Vorlage (alle Seiten, die die Vorlage einbinden, müssen aktualisiert werden)

Abgesehen von Vorlagenänderungen betreffen diese Aktionen zwar nicht die Linktabellen, sie machen jedoch den HTML-Cache aller Seiten, auf denen die fragliche Seite verlinkt oder in denen ein Bild eingebunden ist, ungültig. Die Außerkraftsetzung des Caches einer Seite ist ein kurzer Vorgang; dazu wird nur die Aktualisierung eines einzigen Datenbankfelds und das Senden eines Multicast-Datenpakets zur Cacheleerung benötigt. Es dauert allerdings länger, wenn mehr als 1000 Aktualisierungen vorzunehmen sind. Standardmäßig werden Jobs hinzugefügt, wenn mehr als 500 Seiten betroffen sind; ein Job pro 500 Vorgänge.

Beachte jedoch, dass das Bereinigen einer komplexen Seite, die sich nicht im Cache befindet, teuer werden kann, auch wenn das Bereinigen des Caches einer Seite nur ein kurzer Vorgang ist. Dies gilt insbesondere dann, wenn eine stark genutzte Vorlage bearbeitet wird und viele Seiten in kurzer Zeit bereinigt werden müssen und dein Wiki viele gleichzeitige Besucher hat, die eine große Bandbreite an Seiten laden. Das lässt sich abmildern, indem du die Anzahl der Seiten, die in einem kurzen Zeitraum gelöscht werden, reduzierst, indem du $wgUpdateRowsPerJob auf eine kleine Zahl (z.B. 20) und auch $wgJobBackoffThrottling für htmlCacheUpdate auf eine niedrige Zahl (z.B. 5) setzt.

Audio- und Video-Transkodierung

Wenn du TimedMediaHandler für die Verarbeitung lokaler Uploads von Audio- und Videodateien verwendest, wird die Jobwarteschlange genutzt, um die potenziell sehr langsame Erstellung von abgeleiteten Transcodes in verschiedenen Auflösungen/Formaten durchzuführen.

Diese sind nicht geeignet, um auf Anfragen im Web zu laufen - du brauchst einen Hintergrund-Runner.

Es wird empfohlen, für die Jobtypen webVideoTranscode und webVideoTranscodePrioritized nach Möglichkeit separate Runners einzurichten. Diese beiden Warteschlangen verarbeiten unterschiedliche Teilmengen von Dateien - die erste für hochauflösende HD-Videos und die zweite für Videos und Audiodateien mit geringerer Auflösung, die schneller verarbeitet werden.

Typische Werte

In Zeiten geringer Serverlast kann die Jobwarteschlange leer sein und den Wert Null haben. In der Praxis ist die Jobwarteschlange – zumindest in den großen Wikimediaprojekten wie zum Beispiel der deutschsprachigen Wikipedia – fast nie leer. Außerhalb der Tagesspitzenzeiten kann sie einige hundert bis tausende anstehende Jobs umfassen, in Spitzenzeiten auch mehrere Millionen. Der Zahlenwert kann sehr kurzfristig um 10 Prozent oder mehr schwanken. [1]

Spezial:Statistiken

Bis MediaWiki 1.16 wurde der Wert der Job-Warteschlange auf Special:Statistics angezeigt. Seit 1.17 (rev:75272) wurde sie jedoch entfernt und kann jetzt mit API:Seiteninfo angezeigt werden:

api.php?action=query&meta=siteinfo&siprop=statistics [In der ApiSandbox ausprobieren]

Die Anzahl der Jobs, die im API-Ergebnis zurückgegeben wird, kann etwas ungenau sein, wenn du MySQL benutzt, das die Anzahl der Jobs in der Datenbank schätzt. Diese Zahl kann je nach der Anzahl der kürzlich hinzugefügten oder gelöschten Stellen schwanken. Bei anderen Datenbanken, die keine Unterstützung für eine schnelle Schätzung der Ergebnisgröße bieten, wird die tatsächliche Anzahl der Jobs angegeben.

Für Entwickler

Code-Verwaltung

Siehe auch

Retrieved from "https://www.mediawiki.org/w/index.php?title=Manual:Job_queue/de&oldid=6541084"