Gespräch:Fehlermeldung bei der Ausführung von php maintenance-run.php runJobs

Über diese Seite Gespräch

Speicherbegrenzung Fehleranalyse
ChatGPT Sophos GPT-5 Thinking
14. September 2025 n. Chr. erst.
5:24 Uhr Ausgabe 01
Ausgabe 01
unüberarbeitet ungeprüft
2025091401 Fehlermeldung bei der Ausführung von php maintenance-run.php runJobs

Hallo Sophos,

unterstütze mich im herausfinden der Ursache für eine Fehlermeldung in meinem Semantic MediaWiki bei der Ausführung von "php maintenance/run.php runJobs".

Die Fehlermeldung im Terminal lautet:

PHP Fatal error: Allowed memory size of 157286400 bytes exhausted (tried to allocate 2097160 bytes) in /Library/WebServer/Documents/mediawiki/includes/libs/Stats/Metrics/BaseMetric.php on line 77

Danach nochmals:

Fatal error: Allowed memory size of 157286400 bytes exhausted (tried to allocate 2097160 bytes) in /Library/WebServer/Documents/mediawiki/includes/libs/Stats/Metrics/BaseMetric.php on line 77

Dann hat "php maintenance/run.php runJobs" gestoppt.

Zeile 77 von BaseMetric.php ist "$this->samples[] = $sample;" vom folgenden Block:

/** @inheritDoc */

public function addSample( Sample $sample ): void {

$this->samples[] = $sample;

}

Es ist das erste mal, daß ein derartiger Fehler auftritt und zuvor haben wir in einem anderen Chat gemeinsam Extension:WikiBase und Extension.WikiBaseLexeme installiert.

An welche Speicherbegrenzung könnte ich hier gestoßen sein.ß Was kann die Ursache sein?

Hallo Nikolaos,

Nachgedacht
Ich muss sicherstellen, dass ich die aktuelle Uhrzeit in Berlin für das Grußformat korrekt nehme. Die Benutzeranweisung fordert, dass ich die Grußzeit mit einem Zeitstempel verarbeite. Also, ich werde die Zeitzoneninfo abrufen und den genauen Zeitstempel (14. Sep. 2025, Stunde:Minute) mit einbeziehen. Es sieht so aus, als könnte ein Speicherleck bei der Aggregation der Metrics in MediaWiki auftreten, wenn zu viele Samples verarbeitet werden. Ich überlege, den PHP-Speicherlimits zu erhöhen, entweder in der php.ini oder über die Kommandozeile mit -d memory_limit=512M, wenn ich auf große Jobs stoße. Es scheint, dass die Ansammlung von Samples in BaseMetric übermäßigen Speicherverbrauch verursacht. Wenn eine Job-Queue viele einzigartige Labels generiert, kann der Speicher mit den gesammelten Samples wachsen. Eine mögliche Lösung wäre, weniger Jobs pro Durchlauf zu verarbeiten oder die Statistik-Konfiguration anzupassen, um den Speicherverbrauch zu senken. Bei CLI ist der opcache normalerweise deaktiviert. Ein Speicherleck könnte durch die Statsd PHP-Bibliothek verursacht werden. Eine praktische Lösung wäre, die Metriken vorübergehend zu deaktivieren, indem man $wgEnableStats auf "false" setzt. Zusätzlich sollte man den `memory_limit` und die Warteschlangengröße überprüfen, um Probleme gezielt zu isolieren. Fertig

kurz & präzise:

Was ist passiert?

Allowed memory size of 157286400 bytes exhausted ⇒ dein PHP memory_limit (CLI) liegt bei 150 MiB (157 286 400 B = 150×1024×1024).
Der Fehler entsteht beim Sammeln von Metrik-Samples (BaseMetric::$samples[] = $sample;). Ein langer Job-Lauf hat so viele Samples angehäuft, dass 150 MiB nicht mehr reichen.

Schnellmaßnahmen (sofort probieren)

Einmalig mehr Speicher geben (nur für diesen Lauf):
- php -d memory_limit=512M maintenance/run.php runJobs
- (Bei großem Backlog ggf. 768M oder 1024M testen.)
In kleineren Chargen laufen lassen (verhindert Sample-Staus im selben Prozess):
- php -d memory_limit=512M maintenance/run.php runJobs --maxjobs 200
- („200“ als Startwert; bei Bedarf kleiner/größer.)
Problematische Jobtypen isolieren (um den Übeltäter zu finden):
- php maintenance/showJobs.php --group # dann z.B.: php -d memory_limit=512M maintenance/run.php runJobs --type refreshLinks --maxjobs 200 php -d memory_limit=512M maintenance/run.php runJobs --type wikibase-addUsagesForPage --maxjobs 200 php -d memory_limit=512M maintenance/run.php runJobs --type smw.update --maxjobs 200

Dauerhafte Abhilfe / Ursachen eingrenzen

CLI-memory_limit erhöhen (nicht zu hoch fürs Tagesgeschäft, aber für Wartung sinnvoll, z. B. 512M):
- Pfad finden: php -i | grep "Loaded Configuration File"
- In der CLI-php.ini memory_limit = 512M setzen (gilt nur für CLI, nicht für FPM/Apache).
Metriken/Monitoring vorübergehend deaktivieren, falls konfiguriert (StatsD/Prometheus o. ä.): Kommentiere in LocalSettings.php deine Metrics-/Stats-Konfiguration testweise aus. Wenn der Fehler dann weg ist, war die Metrik-Sampling-Menge der Trigger (BaseMetric puffert Samples pro Prozess).
Jobs nach Installation von Wikibase/Lexeme & SMW: Nach Neuinstallationen entsteht oft ein großer Backlog (Links neu berechnen, Usages, SMW-Updates). Daher:
- Zuerst mit kleinen --maxjobs mehrere Läufe machen.
- Optional nachts per Cron in Chargen abarbeiten.

Nützliche Prüfungen

Aktuelles CLI-Limit verifizieren: php -r 'echo ini_get("memory_limit"), PHP_EOL;'
Backlog-Größe anschauen: php maintenance/showJobs.php --group

Einschätzung (Fakten vs. Mutmaßung)

Fakt: Die 150 MiB stammen vom PHP-memory_limit der CLI.
Mutmaßung (hoch plausibel): Die Kombination aus großem Jobbacklog (durch Wikibase/Lexeme/SMW) und aktivem Metrics-Sammeln führte zu einem vollen Samples-Array im langlaufenden Prozess.

Wenn du mir kurz die Ausgabe von showJobs.php --group gibst sowie dein aktuelles CLI-memory_limit, kann ich dir sagen, welchen Jobtyp du zuerst und mit welcher Batchgröße am effizientesten leerst – und ob sich ein temporäres Deaktivieren der Metriken bei dir lohnt.

Du:

1. php -r 'echo ini_get("memory_limit"), PHP_EOL;'

Antwort:

1024M

2. php maintenance/showJobs.php --group

*******************************************************************************

NOTE: Do not run maintenance scripts directly, use maintenance/run.php instead!

      Running scripts directly has been deprecated in MediaWiki 1.40.

      It may not work for some (or any) scripts in the future.

*******************************************************************************

smw.changePropagationDispatch: 1736 queued; 0 claimed (0 active, 0 abandoned); 0 delayed

smw.changePropagationClassUpdate: 0 queued; 1 claimed (0 active, 1 abandoned); 0 delayed

cirrusSearchLinksUpdate: 23962 queued; 0 claimed (0 active, 0 abandoned); 0 delayed

cirrusSearchElasticaWrite: 2382 queued; 2 claimed (2 active, 0 abandoned); 0 delayed

webVideoTranscode: 0 queued; 18 claimed (0 active, 18 abandoned); 0 delayed

webVideoTranscodePrioritized: 0 queued; 12 claimed (0 active, 12 abandoned); 0 delayed

replaceText: 0 queued; 8 claimed (0 active, 8 abandoned); 0 delayed

refreshLinks: 0 queued; 1 claimed (0 active, 1 abandoned); 0 delayed

aewi@M1Server mediawiki %

Da wurden einige Jobs abgebrochen.

Da ich alleiniger User des MediaWiki bin, wird eine Erhöhung des Memory für diese Aufgabe keinen Nachteil in Performance haben.

Im welchem Verzeichnis liegt die CLI-php.ini?

Müßte ich nicht bei MediaWiki eher die php.ini ämdern?

ChatGPT:

Nachgedacht
To adjust memory settings: Check PHP version with `command -v php` and verify with `php --ini`. If using Homebrew: `/opt/homebrew/etc/php/8.3/php.ini`. For macOS built-in: `/etc/php.ini`. For MAMP, it may be custom. In `LocalSettings.php`, set `$wgMemoryLimit = "512M"` or `"1024M"`. Also, check for existing `$wgMemoryLimit` or `memory_limit`. Consider clearing metrics or disabling Statsd. Confirm memory settings first. Stick to the known flags: `--type`, `--maxjobs`, `--maxtime`, `--nothrottle`. For Cirrus jobs, ensure Elasticsearch is reachable (queued means not running). The CLI memory is currently set to 1024M, but an earlier crash showed 150M—likely `$wgMemoryLimit`. Check and adjust in LocalSettings by adding `$wgMemoryLimit = "1024M";` after cache setup. If CLI only, use `if (PHP_SAPI === 'cli')`. Fertig

Danke für die Daten – damit klärt sich der Widerspruch:

Dein aktuelles CLI-Limit ist 1024M.
Der Crash lief aber mit exakt 150 MiB (157 286 400 B). Das heißt: irgendetwas setzt für den Job-Lauf das Limit auf 150M herunter.

Am häufigsten sind es zwei Ursachen:

$wgMemoryLimit in LocalSettings.php MediaWiki setzt damit selbst ini_set('memory_limit', …) – auch im CLI. → Suche danach:
```
grep -n "wgMemoryLimit" LocalSettings.php
grep -n "memory_limit" LocalSettings.php
```
Wenn dort z. B. "$wgMemoryLimit = '150M';" steht: auf "1024M" setzen (oder temporär auskommentieren).
Anderes PHP bzw. andere php.ini beim Scriptlauf Auch wenn php -r 'echo ini_get("memory_limit")' 1024M zeigt, kann maintenance/run.php über ein anderes php gestartet worden sein (anderer Pfad, andere ini). → Prüfen:
```
command -v php
php -v
php --ini     # zeigt "Loaded Configuration File" + zusätzliche .ini
```
Typische macOS-Pfade:
- Homebrew: /opt/homebrew/etc/php/8.x/php.ini
- (älter) Systemweit: /etc/php.ini (oft nicht vorhanden)
- MAMP/XAMPP haben eigene php.ini unter deren Verzeichnissen

Was du konkret tun kannst (robust & schnell)

A) Ursache fixieren

Variante 1 (MediaWiki-seitig, sicher): in LocalSettings.php nur fürs CLI hochsetzen:
```
if ( PHP_SAPI === 'cli' ) {
    ini_set( 'memory_limit', '1024M' );
}
```
(Alternativ: \$wgMemoryLimit = "1024M"; global – wirkt dann auch für Webrequests.)
Variante 2 (php.ini anpassen):
```
memory_limit = 1024M
```
Finde die richtige Datei mit php --ini und setze dort: Danach einmal neu testen:
```
php -r 'echo ini_get("memory_limit"), PHP_EOL;'
```

B) Jobs geordnet abarbeiten (und Speicherpeak vermeiden)

Du hast große Backlogs, v. a. CirrusSearch und SMW-Propagation:

In Chargen laufen lassen (reduziert Sample-/Heap-Wachstum pro Prozess):

php maintenance/run.php runJobs --type cirrusSearchLinksUpdate --maxjobs 300
php maintenance/run.php runJobs --type cirrusSearchElasticaWrite --maxjobs 300
php maintenance/run.php runJobs --type smw.changePropagationDispatch --maxjobs 150

(Bei Bedarf --maxjobs kleiner machen, wenn du wieder in hohe Peaks läufst.)

Vorher optional hart ein hohes Limit geben (zusätzlich zur A-Konfiguration): php -d memory_limit=1024M maintenance/run.php runJobs --type cirrusSearchLinksUpdate --maxjobs 300
„claimed/abandoned“ in deiner Ausgabe sind Alt-Claims; wenn du sauber über maintenance/run.php arbeitest, normalisiert sich das. Relevanter sind die queued Werte.

Warum der Crash genau an `BaseMetric::$samples[]`

Das ist nur die Stelle, an der der Speicher voll wurde. Lange Prozessläufe mit vielen Jobs sammeln Metrik-Samples im Prozess; eigentliche Treiber sind die job-spezifischen Datenstrukturen (v. a. Cirrus/SMW), nicht diese eine Zeile. Mit:

höherem (korrektem) memory_limit und
kleineren Chargen vermeidest du die Peaks.

Kurzer Check-Plan (3 Minuten)

grep in LocalSettings.php → alles gefunden? wgMemoryLimit/ini_set('memory_limit', …) anpassen.
php --ini → richtige php.ini identifizieren; falls nötig memory_limit=1024M setzen.
Jobs typenweise in Chargen abarbeiten (Reihenfolge: CirrusLinksUpdate → ElasticaWrite → SMW-Dispatch).

Wenn du magst, poste mir kurz die Treffer aus grep -n "wgMemoryLimit\|memory_limit" LocalSettings.php und die erste Zeile von php --ini („Loaded Configuration File …“). Dann sage ich dir exakt, wo du bei dir am besten drehst und welche Batchgrößen für die drei Jobtypen erfahrungsgemäß gut laufen.

Du:

Danke für die Hinweise.

Auf https://www.mediawiki.org/wiki/Manual:$wgMemoryLimit steht folgendes:

$wgMemoryLimit default 50M

The installation script used to insert ini_set( 'memory_limit', '20M' ); in LocalSettings.php if the memory limit was below 20M.

In meinem LocalSettings.php ist kein Eintrag zu $wgMemoryLimit enthalten.

Soll ich "$wgMemoryLimit = '1024M';" setzen?

ChatGPT:

Nachgedacht
Ich empfehle, das $wgMemoryLimit auf '1024M' in der LocalSettings zu setzen, um sicherzustellen, dass der CLI-Prozess respektiert wird. PHP.ini könnte auch verwendet werden, doch früher war die effektive Einstellung bei 150M. Setze es früh in LocalSettings, idealerweise nach den "includes". Für Web wird 256-512M empfohlen. Fertig

Kurzantwort: Ja. Setze $wgMemoryLimit — das ist der saubere MediaWiki-Weg und stellt sicher, dass auch CLI-Skripte(runJobs) mit dem gewünschten Limit laufen.

Empfohlene Einstellung

Wenn du fürs Web sparsam bleiben willst, aber CLI großzügig:

# In LocalSettings.php (am besten relativ weit oben, nach $wgServer etc.)
$wgMemoryLimit = '512M';            // für Webrequests ausreichend
if ( PHP_SAPI === 'cli' ) {
    $wgMemoryLimit = '1024M';       // für Wartungsskripte/runJobs
}

Wenn dir egal ist, dass auch Web 1 GiB bekommt, kannst du einfach: $wgMemoryLimit = '1024M';

Warum das hilft

MediaWiki setzt beim Start ini_set('memory_limit', $wgMemoryLimit).
Damit überschreibst du die 150 MiB, die bei dir effektiv gegriffen haben (wahrscheinlich von irgendwoher vererbt), auch im CLI-Kontext.

Verifizieren

Nach dem Speichern: php maintenance/run.php eval.php -- 'echo ini_get("memory_limit"), PHP_EOL;'

Sollte 1024M (im CLI-Fall) ausgeben.

Danach Jobs wieder anwerfen (am besten in Chargen)

php maintenance/run.php runJobs --type cirrusSearchLinksUpdate --maxjobs 300
php maintenance/run.php runJobs --type cirrusSearchElasticaWrite --maxjobs 300
php maintenance/run.php runJobs --type smw.changePropagationDispatch --maxjobs 150

Wenn noch Fragen: zeig mir kurz die Ausgabe des eval.php-Checks—dann feintunen wir ggf. (Batchgrößen, Reihenfolge).

Du:

1. Ich habe $wgMemoryLimit = '1024M'; gesetzt

2. zu "Verifizieren Nach dem Speichern":

php maintenance/run.php eval.php -- 'echo ini_get("memory_limit"), PHP_EOL;'

gibt keine Antwort sondern startet irgendetwas oder bleibt mit ">" hängen.

3. Ich habe php maintenance/run.php runJobs erneut gestartet.

Während es zuvor häufig "Fatal Error …" wegen Memory gab, trat die Warnung seither nicht weiter auf.

Nachteile in Performance habe ich keine bemerkt. Der Fehler scheint damit behoben. Danke für deine Unterstützung. Wir wenden uns hiernach wieder dem vorhergehenden Thema Extension:WikiBaseLexeme zu.

ChatGPT:

Nachgedacht
Ich denke, das Problem könnte durch fehlende und zusätzliche Zeichen wie Anführungszeichen oder die Art und Weise, wie die Shell die doppelten Anführungszeichen verarbeitet, entstehen. Die Verwendung von `eval.php` sollte funktionieren, aber die Shell könnte die inneren Anführungszeichen nicht korrekt verarbeiten, was zu einer interaktiven Eingabeaufforderung führt. In zsh sollten Single-Quotes das Problem nicht verursachen, aber der ">"-Prompt deutet darauf hin, dass ein Anführungszeichen fehlt – das kann passieren, wenn die Shell denkt, dass ein Zitat nicht geschlossen wurde. Das bedeutet wahrscheinlich, dass die Ausführung ohne Parameter die interaktive Eingabeaufforderung startet. Ein Vorschlag: Einfach mit Ctrl-D beenden und den `--eval`-Parameter nutzen. Die korrekte Verwendung von `eval.php` für MediaWiki scheint `php maintenance/run.php eval.php -- 'echo ini_get("memory_limit");'` zu sein. Dies funktioniert nach der Dokumentation, da es den PHP-Code innerhalb von MediaWiki ausführt. Der ">" Prompt deutet darauf hin, dass der Code nicht korrekt verarbeitet wurde. Die Frage zur Bereinigung von verlassenen Ansprüchen könnte am besten durch das Verwenden des Warteskripts wie `runJobs` mit der Option `--wait` erfolgen. Für den Job-Queue gibt es verschiedene Skripte wie `cleanupAbandonedJobs.php` oder `cleanupPendingTables.php`, aber einige Aufgaben könnten sich auch automatisch löschen. Fertig

Super — dann haben wir die Ursache gefunden und sauber entschärft. 👍

Kurz zur eval.php-“>” Prompt:

Das > ist der interaktive Prompt von eval.php. Er erscheint, wenn du eval.php ohne auswertbaren Einzeiler gestartet hast (oder wenn die Shell-Quotes nicht passten). Beenden mit Strg-D.
Für einen Einzeiler (nicht-interaktiv) nimm am besten abwechselnde Anführungszeichen, dann kollidiert nichts:
```
php maintenance/run.php eval.php -- "echo ini_get('memory_limit'), PHP_EOL;"
```
(Oder umgekehrt mit inneren "…", äußeren '…'.)

Zum Ergebnis:

Mit $wgMemoryLimit = '1024M'; ist dein Job-Runner jetzt unter MediaWiki-Kontrolle bei 1 GiB gelandet; deshalb sind die vorherigen „Allowed memory size … 150 MiB“ weg. Performance-Nachteile im Ein-User-Setup sind hier praktisch nicht zu erwarten.

Kleiner Betriebs-Tipp (optional):

php maintenance/run.php runJobs --type cirrusSearchLinksUpdate --maxjobs 300
php maintenance/run.php runJobs --type cirrusSearchElasticaWrite --maxjobs 300
php maintenance/run.php runJobs --type smw.changePropagationDispatch --maxjobs 150

Wenn du künftig wieder große Backlogs hast (z. B. nach Schema- oder Masseneingriffen), kannst du weiterhin in Chargen laufen lassen:

Das hält Speicherpeaks pro Prozess klein.

Wenn du soweit durch bist, springen wir gern zurück zu WikibaseLexeme. Sag einfach, womit wir dort konkret ansetzen sollen (z. B. Sinnvolle erste Lexeme-Workflows, Properties/Forms, SMW-Brücken, oder Indizierung/Cirrus-Best-Practices).

Du:

Danke für die Hinweise.

Derzeit ändere ich viele Einträge und Kategorien mittels RplaceText.

Ich muß keine Rücksicht auf Performance nehmen, kann also große Aufgaben in einem Rutsch ausführen lassen, was mir lieber ist, da ich dann damit schneller durch bin und die nächste größere Aufgabe angehen kann.

cirrusSearchElasticaWrite hat noch 2285 queued und läuft nun durch, ohne daß ich immer wieder neue Chargen starten muß.

ChatGPT:

Nachgedacht
We need to respond warmly and acknowledge progress here. The web.run isn’t required; it’s a local tech process. When dealing with large batches, remember potential pitfalls: Elasticsearch issues, disk watermarks, and throttle settings. Running jobs in parallel could work, but be cautious with job concurrency and DB locking. Have ReplaceText specifics stored, and consider SMW rebuild after ReplaceText jobs. When many categories change, SMW handles the propagation, but running an SMW rebuild could be heavy, though not always necessary if jobs work. After ReplaceText, expect both CirrusSearchElasticaWrite and LinksUpdate jobs. Consider temporarily adjusting CirrusSearch write queue and Elasticsearch batch sizes, but keep things simple unless needed. To maintain stability during a "one-shot" run, check the memory limit and consider setting `set_time_limit(0)` for PHP. For the `runJobs` script, options like `--maxjobs`, `--maxtime`, and `--n-threads` can be used, but avoid unclear flags. You might want to adjust CirrusSearch index settings temporarily for bulk indexing efficiency. To avoid misinformation, it’s important to monitor Elasticsearch’s heap usage and disk space. You can check Elasticsearch health with these commands: `curl 'http://localhost:9200/_cat/health?v'` `curl 'http://localhost:9200/_cat/indices?v'` `curl -XGET 'http://localhost:9200/_nodes/stats/jvm?pretty'` Remember to monitor for "circuit_breaking_exception" and low disk watermark issues. Also, after ReplaceText tasks, manage redirects and clean up unused categories. Fertig

Klingt gut — dann lass ihn „durchrödeln“. 👍

Ein paar kompakte Profi-Hinweise für deinen „Alles-in-einem-Rutsch“-Ansatz mit ReplaceText + Cirrus/SMW:

Stabil & schnell bei großen Job-Wellen

Speicherlimit passt jetzt. Für lange Läufe kannst du zusätzlich (optional) pro Prozess die Peaks klein halten, indem du typenweise abarbeitest (nur wenn du merkst, dass es stockt):
```
php maintenance/run.php runJobs --type cirrusSearchLinksUpdate
php maintenance/run.php runJobs --type cirrusSearchElasticaWrite
php maintenance/run.php runJobs --type smw.changePropagationDispatch
```
(Ohne --maxjobs läuft er komplett durch – genau dein Stil.)
Elasticsearch im Blick behalten (falls lokal): Bei sehr großen Writes prüfen:
```
curl -s localhost:9200/_cat/health?v
curl -s localhost:9200/_cat/indices?v
curl -s localhost:9200/_nodes/stats/jvm?pretty | grep -E "heap_used|heap_max" -n
```
Wenn Heap >75–80 % klettert oder der Cluster gelb/rot wird, kurz pausieren und weiterlaufen lassen. Häufige Bremsen: low/high disk watermark oder circuit_breaker (Heap). Dann Platz schaffen bzw. ES neu starten.
Nach großen ReplaceText-Läufen mit Seitenverschiebungen (Titeländerungen):
- Doppelte Weiterleitungen reparieren: php maintenance/run.php fixDoubleRedirects.php
- Optional: Links neu berechnen, falls du Unstimmigkeiten siehst: php maintenance/run.php refreshLinks.php (Beides triggert erneut Jobs—bei dir okay.)
SMW-Konsistenz
- Normalfall: Jobs genügen (smw.changePropagation…).
- Nur falls du echte Inkonsistenzen siehst (fehlende/alte Werte trotz fertiger Jobs): php extensions/SemanticMediaWiki/maintenance/rebuildData.php --with-maintenance-log (Vorher Jobqueue leer laufen lassen; rebuild ist die „große Keule“.)
ReplaceText-Tipp
- Wenn du Kategorienamen massenhaft änderst: leere Alt-Kategorien kannst du später leicht finden (Spezialseiten: Wanted/Orphaned/Unused Categories) und wegräumen.

Kurzfazit

$wgMemoryLimit = '1024M'; hat dein ursprüngliches 150-MiB-Bottleneck entfernt.
Du kannst die restlichen cirrusSearchElasticaWrite in einem Rutsch durchlaufen lassen.
Behalte nur ES-Heap und Platte im Auge; ansonsten: laufen lassen.

Wenn du bereit bist, springen wir nahtlos zu WikibaseLexeme weiter. Was ist dein nächster Schritt dort? (z. B. sinnvolle Property-Sets für Lexeme, Workflows fürs Anlegen/Verknüpfen, oder SMW-Brücke/Abfragen über Lexeme?)

Du:

Danke für die Hinweise, werde ich nach Bedarf beachten.

Zur Kenntnisnahme:

Du gabst mir die Anweisung php maintenance/showJobs.php --group

der richtigere Befehl für MW ab 1.40 lautet php maintenance/run.php showJobs --group

Ich muß keine Jobs nach JobTyop zur ausführung bringen, ich lasse sie einfach alle ausführen – das Ausführen behindert meine Tätigkeit nicht wirklich.

ChatGPT:

Nachgedacht
Nikolaos bevorzugt formelle oder informelle Ansprache. Da dies jedoch keine neue Unterhaltung ist, gebe ich keinen Zeitstempel an. Ich stelle also die korrigierten Befehle zur Verfügung: Ein bash-Skript wie „while php maintenance/run.php showJobs –quiet \| grep -q 'queued'; do php maintenance/run.php runJobs –maxjobs 500; done“ funktioniert. Erwähne auch die --wait Option für kontinuierliche Ausführung. Es scheint, dass `runJobs --wait` in MW 1.39+ tatsächlich dazu dient, nicht zu beenden, wenn die Warteschlange leer ist, sondern auf neue Jobs zu warten. Um klare Befehle zu geben: `showJobs: php maintenance/run.php showJobs --group` Alle Jobs ausführen: `php maintenance/run.php runJobs` Limitierte Ausführung: Mit `--maxjobs N` Bestimmte Jobs: Mit `--type` Fix für Double Redirects: `php maintenance/run.php fixDoubleRedirects` Links aktualisieren: `php maintenance/run.php refreshLinks` Daten neu aufbauen: `php extensions/SemanticMediaWiki/maintenance/rebuildData.php` und auch `maintenance/run.php` verwenden. Fertig

Guter Hinweis, danke! Du hast völlig recht: ab MW 1.40 ist der korrekte Aufruf php maintenance/run.php showJobs --group

Ich korrigiere meine Notation entsprechend.

Kurz-Cheat-Sheet (MW 1.40+), passend zu deinem „alles in einem Rutsch“-Vorgehen: php maintenance/run.php showJobs --group

Job-Übersicht gruppiert
Alle Jobs komplett abarbeiten (ohne Typfilter) php maintenance/run.php runJobs
Optional: große Läufe mit hartem Limit (nur falls nötig) php -d memory_limit=1024M maintenance/run.php runJobs
Doppelte Weiterleitungen reparieren (nach großen Umbenennungen/ReplaceText) php maintenance/run.php fixDoubleRedirects
Links neu berechnen (nur bei Bedarf) php maintenance/run.php refreshLinks
SMW-Rebuild (nur wenn Inkonsistenzen sichtbar bleiben; große Keule) php maintenance/run.php extensions/SemanticMediaWiki/maintenance/rebuildData.php -- --with-maintenance-log (Hinweis: Bei Extension-Skripten den doppelten -- für run.php-Weitergabe beibehalten.)

Dein Ansatz, die Queue einfach durchlaufen zu lassen, ist in deinem Setup absolut ok—zumal das Memory-Thema jetzt sauber gelöst ist. Wenn du ready bist, springen wir zurück zu WikibaseLexeme.

Hallo Nikolaos,

Was ist passiert?

Schnellmaßnahmen (sofort probieren)

Dauerhafte Abhilfe / Ursachen eingrenzen

Nützliche Prüfungen

Einschätzung (Fakten vs. Mutmaßung)

Du:

ChatGPT:

Was du konkret tun kannst (robust & schnell)

A) Ursache fixieren

B) Jobs geordnet abarbeiten (und Speicherpeak vermeiden)

Warum der Crash genau an BaseMetric::$samples[]

Kurzer Check-Plan (3 Minuten)

Du:

ChatGPT:

Empfohlene Einstellung

Warum das hilft

Verifizieren

Danach Jobs wieder anwerfen (am besten in Chargen)

Du:

ChatGPT:

Du:

ChatGPT:

Stabil & schnell bei großen Job-Wellen

Kurzfazit

Du:

ChatGPT:

Warum der Crash genau an `BaseMetric::$samples[]`