Speicherproblem mit Mod-Rewrite?

[bodil]

Hallo zusammen,
eine Contenido-Installation (4.9.12, PHP 5.6.38) schreibt immer wieder Fehler wie die folgenden ins Error-Log:

Code: Alles auswählen

[01-Feb-2019 19:33:11 Europe/Berlin] PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 18725783 bytes) in /***/contenido/plugins/mod_rewrite/includes/functions.mod_rewrite.php on line 482
[01-Feb-2019 19:32:47 Europe/Berlin] PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 25464569 bytes) in /***/contenido/plugins/mod_rewrite/includes/functions.mod_rewrite.php on line 510

In diesen Zeilen finden nur Ersetzungen statt:

Code: Alles auswählen

        // remove fucking tinymce single quote entities:
        $code = str_replace("'", "'", $code);

(482) und

Code: Alles auswählen

        // define some preparations to replace /front_content.php & ./front_content.php
        // against front_content.php, because urls should start with front_content.php
        $aPattern = array(
            '/([\"|\'|=])\/front_content\.php(.?|.+?)([\"|\'|>])/i',
            '/([\"|\'|=])\.\/front_content\.php(.?|.+?)([\"|\'|>])/i'
        );
        $aReplace = array(
            '\1front_content.php\2\3',
            '\1front_content.php\2\3'
        );
        // perform the pre replacements
        $code = preg_replace($aPattern, $aReplace, $code);

(510)
Wobei der Fehler in Zeile 510 häufiger ist.
Über den verfügbaren Speicher schreibt Contenido:

Code: Alles auswählen

memory_limit 	128M

Kann mir jemand erklären, wie es zu dieser Fehlermeldung kommt? Was braucht da so viel Speicher?
Und wie sich der Fehler auswirkt? Bei der Benutzung der Seite ist mir noch kein Problem aufgefallen.
Vielen Dank!
Bodil

[xmurrix]

Es ist vermutlich die Verwendung von preg_replace_callback(), die in den Zeilen 482 u. 510 für die Ersetzungen verwendet wird.

Dazu gibt es auch ein PHP Bug Report:
https://bugs.php.net/bug.php?id=61792

Wenn man nach "preg_replace_callback memory leak" googelt, findet man einige User mit ähnlichen Problemen. Vielleicht löst das Hochschrauben des Memory-Limit das Problem...

[bodil]

Vielen Dank! Da muss ich mal sehen, ob das möglich ist.

[bodil]

Da hätte ich jetzt doch noch eine Frage:
Gesetzt den Fall, das eigentliche Problem liegt woanders, irgendwas anderes verbrauch wahnsinnig viel Speicher, so dass er fürs Mod-Rewrite nicht mehr reicht - gäbe es irgendeine Debugging-Methode, das rauszufinden? Eine Art Task-Manager für Seitenaufrufe zum Dazuinstallieren?
Hintergrund der Frage: ich betreue keine Seite, der mehr als 128 MB zur Verfügung stehen, der Fehler tritt sonst aber nirgendwo auf.
Dank und Gruß!
Bodil

[xmurrix]

Es ist nur eine Vermutung, dass die Funktion preg_replace_callback() die Ursache dafür ist, vielleicht ist aber auch das AMR-Plugin das Problem. Man müsste das Ganze näher prüfen.

Zum Analysieren des Speicherverbrauchs in PHP gibt es die PHP Erweiterung Xdebug. Damit kann man sehr gut herausfinden, was da in PHP passiert, die generierten Log-Dateien lassen sich in Qcachegrind anzeigen. Oder man richtet sich die IDE so ein, dass man darüber den PHP Code debuggen kann.

Ich würde aber auch folgendes berücksichtigen:

Das AMR-Plugin registriert sich für den Hook 'Contenido.Frontend.HTMLCodeOutput', sofern die Umwandlung der URLs bei der Ausgabe konfiguriert wurde. Ist das der Fall, und die ausgegebene Seite ist z. B. eine Google-Sitemap mit sehr vielen Einträgen, kann das die Ursache sein. Bei so einem Fall schlage ich vor, die Seite von der Ausgabepufferung auszunehmen, damit AMR nicht versucht, die URLs umzuwandeln. Dafür muss man selber die generierten URLs im Modul mittels "cUri::getInstance()->build()" ausgeben.
Eine ganz bestimmte Seite lässt sich mit folgender Einstellung aus der Ausgabepufferung ausschließen:

Code: Alles auswählen

Typ: frontend.no_outputbuffer
Nme: idart
Wert: 123

Der Wert kann auch eine kommaseparierte Liste mehrerer idarts sein.

Mann kann auch in AMR die Umwandlung von URLs währen der Ausgabe der Seite ausschalten. Im Gegenzug muss man dafür sorgen, dass alle Plugins und Module die URLs unter Verwendung von "cUri::getInstance()->build()" generieren. Dann muss auch das AMR-Plugin nicht URLs wie "front_content.php" während der Ausgabe der Seite in Clean-URLs umwandeln, weil die build() Funktion von cUri das übernimmt.

Gruß
xmurrix

[bodil]

Damit kann ich weiterforschen!
Vielen Dank für die ausführliche Antwort!
Bodil