out-of-memory durch großen PageTree im Backend

[flx]

Hallo,

die Anzeige großer Seitenstrukturen oder Artikellisten im Backend führt zum Absturz.
Habt ihr Tipps, wie man "damit leben kann"?
Lohnt sich vielleicht eine grundsätzliche Änderung der Architektur von Contao?

Contao (2.10) puffert die Seiten des Backends bei der Ausgabe als String auf dem Stack,
hier zum Beispiel (system/drivers/DC_Table.php:generateTree) bei der Ausgabe
der Seitenstruktur. Dabei wird zu jedem Eintrag der Page-Liste ein Edit/Copy/Paste
Menü generiert, insgesamt geschätzte 20 KB (interner Speicherbedarf!) RAM pro
Eintrag.

Bei mir stürzt Contao mit Meldungen wie

Fatal error: Out of memory (allocated 27787264) (tried to allocate 8192 bytes) in /.../system/libraries/Controller.php on line 2342

ab, sobald die Seitenstruktur mehr als 800 Seiten umfasst (=> daraus die Speicherschätzung oben).

Ich würde einfach mal in Frage stellen, ob es nötig ist, die Backendseiten in einer PHP-Variablen
zu puffern und fertig auszugeben. Warum nicht einfach raus über STDOUT?

Grüße,
flx

[xchs]

Kontrolliere mal bitte, wie groß das "Memory Limit" ist, das Dir zur Verfügung steht. Laut Fehlermeldung wären das lediglich um die 27 MB, was bei großen Seiten- oder Artikelstrukturen bzw. beim Einsatz entsprechend umfangreicher Erweiterungen ziemlich sicher zu wenig sein wird. Kannst Du (bzw. Dein Hoster) dieses Limit erhöhen?

[flx]

klar. Die Site liegt bei einem großen Hoster aus Montabaur, der Tarif heißt "Dual Advanced" und bietet laut Vertrag "80 MB Arbeitsspeicher für Scripts". (Kann er auch gerne machen für 15 Euro pro Monat.) PHP selbst meldet als memory_limit 90 MB.

Real scheinen es aber, wie man sieht, eher erheblich weniger, nämlich unter 30 MB zu sein. Zur Differenz schreibt der Support des Hosters: "Wir konnten den Hinweis reproduzieren, jedoch können wir den Fehler niht in unseren Systemen finden." Das kam vor 9 Tagen, seitdem antwortet der Support überhaupt nicht mehr. Obwohl ich echt höflich zu ihnen bin.

Aber genug des Hoster-Bashings: Wenn ich 90 MB RAM hätte, würde Contao bei 2400 Seiten Content abstürzen. Das Backend "verbraucht" m.E. einfach zuviel Speicher. Das CMS skaliert nicht so gut, wie es könnte!

flx.

[flx]

(nur um sicher zu sein, dass ich dem 1und1-Support nicht furchtbar unrecht tue: Contao macht doch nicht irgendwelche Tochterprozesse auf, die sich womöglich eigenen Speicher reservieren, der irgendwie nicht gemeldet wird? Wenn ich an den jeweiligen Absturzstellen vor throw() PHPs "memory_get_usage(TRUE)" aufrufe, bekomme ich auch zwischen 26 und 29 MB gemeldet -- also denselben Speicherverbrauch).

[xchs]

Erstell Dir im Contao Hauptverzeichnis eine neue Datei "phpinfo.php" mit folgendem Inhalt

<?php phpinfo(); ?>

und rufe anschließend dieses Skript im Browser auf. Dort sollte dann auch der Wert für das "Memory Limit" zu finden sein.

[andreasisaak]

Aber genug des Hoster-Bashings: Wenn ich 90 MB RAM hätte, würde Contao bei 2400 Seiten Content abstürzen. Das Backend "verbraucht" m.E. einfach zuviel Speicher. Das CMS skaliert nicht so gut, wie es könnte!

Das stimmt nicht. Mit 27 MB kommt kein CMS zurecht, egal ob TYPO3, Contao, WordPress oder Joomla. Ich hab grade das selbe Problem mit einem 1&1 Webhosting Projekt und letztendlich den Kunden dazu überzeugen können doch auf einen anderen Hoster zu wechseln.

Ich arbeite nur mit Hostern die mehr als 90 MB an Memory Limit bereitstellen und habe in etlichen Installation mehr als 10.000 Seiten in der Seitenstruktur. Das Öffnen ALLER Seiten ist etwas langsam - da hast du recht wenn du von fehlender Performance redest aber das wars auch schon.

[flx]

xchs:
phpinfo() meldet memory_limit 90M 90M (hatte ich aber oben schon erwähnt).

andreas:
ich bleib aber bei meiner Kritik:

Wenn das Backend 20 KB RAM pro Artikel verbraucht -- nur um einen Link auf den Titel und ein paar Buttons anzuzeigen!, -- dann ist das viel zu viel. (Auch Bytes essen Brot.)

Und ich versteh immer noch nicht, warum die ganze vermaledeite Ausgabe gepuffert werden muss, und nicht schon mal blockweise an den Client geht.

War das bei deinem erwähnten Projekt auch so, dass bei 1&1 weniger RAM drin ist als draufsteht?

Grüße an alle,
flx.

[xchs]

phpinfo() meldet memory_limit 90M 90M (hatte ich aber oben schon erwähnt).

Jepp. Ich wollte nur sichergehen, dass Du das Skript bzw. die Funktion auch tatsächlich im Contao Rootverzeichnis aufrufst. Vereinzelt kam es nämlich schon mal vor, dass beispielsweise ein Aufruf der PHP-Konfiguration über das Admin-Panel irgendeine globale Konfiguration ausgab, während der direkte (lokale) Aufruf im Contao-Verzeichnis dann ganz andere Werte zutage brachte. Das könnte z.B. dann der Fall sein, wenn es eine lokale "php.ini" gibt.

[flx]

@xchs:
ok, danke für den tipp, werd ich mir merken!

@alle:
Ich habe 1&1 Unrecht getan, es stehen wirklich 80MB für PHP zur Verfügung.
Jedenfalls lässt sich das mit einem Mini-Skript, das in einer for-Schleife
String-Variablen mit je 1 MB belegt, nachweisen.

Contao steigt aber, wie oben beschrieben, schon unter 30 MB aus:
Bei
(1) Inhalte > Artikel (main.php?do=article)
und
(2) Layout > Seitenstruktur (main.php?do=page)

Im ersten Fall mit der Meldung
Fatal error: Out of memory (allocated 25690112) in system/libraries/Controller.php on line 2342
im zweiten Fall mit
Fatal error: Uncaught exception Exception with message Query error: (SELECT * FROM tl_page WHERE pid='1596' LIMIT 0,1) thrown in /.../rtneu/system/libraries/Database.php on line 691 (bei 28 MB memory_get_usage()).

Beide Fehler sind wirklich Speicherprobleme: ich kann sie beide unterdrücken, indem ich in
/system/drivers/DC_Table.php:3272
bei Speicherüberlauf die Schleife verlasse, die den Pagetree für die Anzeige im Backend formatiert:
if (memory_get_usage()>20000000) break;

Seit PHP 5.3 gibt es ja einen neuen Garbagecollector. Um den zu aktivieren, muss man beim
genannten Hoster die PHP-Version von "PHP5" auf "PHPDEV" umstellen (dann kriegt man derzeit Version 5.4 statt 5.2.10). Das brachte bei mir aber keinen Fortschritt: Unter PHP 5.4 bleiben die Speicherwerte ähnlich (Ausstieg bei 23 MB aus ?do=article, bei 27 MB aus ?do=page).

Grüße @alle,
flx.

[Siegi]

Hi,

ich hatte eben das gleich Problem bei Contao 3.0.5 (viele Seiten, Out-of-memory-Error, memory_limit ausreichend hoch eingestellt), die Seitenstruktur im Backend kann nicht mehr aufgerufen werden.

Weiß jemand, ob in neueren Contao-Versionen eine Lösung für das Problem integriert worden ist?

[Flex]

Das ist kein Fehler von Contao, sondern geschieht einfach aufgrund fehlender Ressourcen.

Die genaue Fehlermeldung wäre hier interessant und welche PHP Version zum Einsatz kommt.

[Siegi]

1) Fehler:
Fatal error: Out of memory (allocated 23592960) (tried to allocate 2983324 bytes) in /.../system/modules/core/classes/BackendTemplate.php on line 153

->tritt nur im Backend bei Layout > Seitenstruktur auf, zB Inhalte > Artikel funktioniert fehlerfrei.

2) PHP
PHP Version 5.4.28
memory_limit 360M 360M

[tab]

Naja, ist wohl mal wieder der Unterschied zwischen memory_limit und dem tatsächlich zur Verfügung stehenden Memory. Mehr als 26MB scheinen ja nicht allokiert zu sein.

Allerdings erscheint mir der Hinweis einige Beiträge weiter oben recht interessant. Das sah ja direkt so aus, als ob flx tatsächlich Memory bis zum Limit hätte allokieren können. Ich werde das gelegentlich nochmal bei 1&1 ausprobieren.

[Siegi]

Nachtrag
bei der Webseite gab es Seiten, die nicht der Root-Seite zugeordnet waren, vielleicht hat das ja zu Performance-Problemen geführt:

select id, pid from tl_page where (pid<>0) and (pid not in (select id from tl_page))
-> hier kommt normalerweise ein leeres Resultset zurück

Ich weiß nicht, wie sowas passieren kann. Wir haben jetzt einen alten DB-Dump einsgespielt. Jetzt läuft alles wieder normal.
Ich werde das mal weiter beobachten.

[Grossvater]

Reines Interesse meinerseits: es lag also nicht am memory_limit, sondern daran, dass Seiten nicht dem Root zugeordnet waren?

[Siegi]

Ja, wahrscheinlich (ich hab mir die Contao-Quellcodes nicht angesehen). Aber als die nicht zugeordneten Seiten nicht mehr existierten, trat auch das Problem nicht mehr auf.