Out of memory in PDOStatement.php (line 146)

[Samson1964]

Ich habe Contao 4.4.7 unter PHP 7.1 installiert und dann meine 3.5er Datenbank importiert. Funktioniert auch alles wunderbar. Bis auf Fehlermeldungen beim Speichern von Seiten oder Seitenlayouts. app_dev.php meldet:

(1/1) OutOfMemoryException
Error: Out of memory (allocated 462274560) (tried to allocate 4096 bytes)
in PDOStatement.php (line 146)

Das in der php.ini eingestellte memory_limit ist 1000M. Wenn ich mich nicht verrechnet habe, steigt Contao aber schon bei rund 441 MB aus.

In var/logs steht es etwas ausführlicher:

php.CRITICAL: Fatal Error: Out of memory (allocated 462274560) (tried to allocate 4096 bytes) 
{"exception":"[object] (Symfony\\Component\\Debug\\Exception\\OutOfMemoryException(code: 0): 
Error: Out of memory (allocated 462274560) (tried to allocate 4096 bytes) 
at /xxx/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php:146)"} []

Ich bin ratlos.

EDIT: Die Speichervorgänge selbst funktionieren übrigens tadellos.

[tab]

Dein Memory Limit ist einfach höher eingestellt als dir der Server an RAM zubilligt. Wenn das memory_limit zuschlägt sieht die PHP Fehlermeldung beispielsweise so aus:

Fatal error: Allowed memory size of 50331648 bytes exhausted (tried to allocate 184320 bytes) in ...

Da steht also drin, wieviele Bytes dir erlaubt sind und dass diese Menge verbraucht ist. Bei deiner Fehlermeldung nicht, da hat der Prozessmanager oder was auch immer zugeschlagen, weil der Prozess mehr Memory verbraucht hat als zulässig. Da kannst du dein memory_limit auf 128GB setzen, das ändert gar nichts.

Warum das Speichern allerdings so viel RAM verbrät ist eine andere Sache, da scheint wohl irgendwo ein Bug zu sein, sei es in Contao oder in Doctrine oder in PHP.

[Spooky]

Reproduziere das mal in der dev Umgebung, evt. hast du da dann einen Stack Trace.

[Samson1964]

Mein erster Codeabschnitt war die Fehlermeldung aus der dev-Umgebung. Die fällt leider sehr viel dürftiger aus, weil wahrscheinlich der Rest der dev-Umgebung gleich mit abstürzt. Ich kann aber nochmal schauen, ob doch noch mehr zu sehen ist.

[Samson1964]

Backend mit app.php:
Weiße Seite mit

Fatal error: Out of memory (allocated 462274560) (tried to allocate 28672 bytes) in 
/xxx/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php on line 146
Fatal error: Out of memory (allocated 462274560) (tried to allocate 36864 bytes) in Unknown on line 0

Backend mit app_dev.php:
Erst nur eine weiße Seite, beim Refresh wie oben im Eröffnungsbeitrag:

Keine weiteren Navigationselemente.

[Spooky]

Und das passiert tatsächlich auch beim Speichern eines Seitenlayouts?

[Samson1964]

Bei einem Seitenlayout war das mal passiert. Im Moment klappt dort aber alles. Beim Speichern einer Seite passiert das. Ich habe aber nur drei Seiten aus der Seitenstruktur getestet.

[Spooky]

Passiert der Fehler auch, wenn du in der Systemwartung die XMLs neu generieren lässt?

[Samson1964]

Ja.

In einer anderen ähnlichen Installation bekomme ich zusätzlich zu obiger Fehlermeldung auch noch:

Fatal error: Out of memory (allocated 462278656) (tried to allocate 65536 bytes) 
in /xxx/vendor/symfony/symfony/src/Symfony/Component/Debug/Exception/OutOfMemoryException.php on line 19

[Samson1964]

Und noch ein Kandidat:

Fatal error: Out of memory (allocated 462278656) (tried to allocate 32768 bytes) 
in /xxx/vendor/twig/twig/lib/Twig/Environment.php on line 620

[Spooky]

Ja.

Dann liegt es an der Sitemap. Wie groß ist deine Installation? Also Anzahl an Seiten, News, Events, etc.
Verwendest du Extensions oder Bundles?

[Samson1964]

1.641 Seiten, 1.046 Events und 13.127 Nachrichten. Es ist eine 4.4.7-Installation unter PHP 7.1 mit einer importierten C3-Datenbank. Unter system/modules habe ich bis jetzt nur 4-5 Erweiterungen der insgesamt etwa 40 reinkopiert. Dazu sind 2 oder 3 Bundles außer dem Corezeug aktiv.

Ich kann ja testweise mal tl_page (nur einen Teil davon), tl_calendar_events oder tl_news löschen und schauen ob der Fehler verschwindet?! Aber wenn Du schon eine heiße Spur hast ....

[Spooky]

Es ist mit hoher Wahrscheinlichkeit das Erzeugen der Sitemap. Da du sehr viel Inhalt hast, geht dir der Speicher aus. Siehe dazu

• https://github.com/contao/core/issues/8728
• https://github.com/contao/core/issues/7928

Du könntest in letzterem Ticket deine Situation posten. Eine mögliche, zukünftige Lösung wird im ersten Ticket diskutiert - nämlich dass die Sitemap nur mehr on-demand und nur mehr pro Website Root generiert wird.

Mittelfristig wird dir aber nur überbleiben auf ein Hosting zu wechseln, wo dir mehr Speicher garantiert wird.

[Samson1964]

Das ist unbefriedigend. Was soll ich denn noch Höheres nehmen als einen ManagedServer? Und warum läuft Contao 3.5 tadellos, während Contao 4.4 schlapp macht. Ist Contao 4 nicht mehr für große Webseiten geeignet?

Die Tickets schaue ich mir im Laufe des Tages an.

EDIT: Unter C3 werden beim Erstellen der XML-Dateien nur 34,4 MB lt. Debugmodus verbraucht.

[Spooky]

EDIT: Unter C3 werden beim Erstellen der XML-Dateien nur 34,4 MB lt. Debugmodus verbraucht.

Ist das sicher der Maximalverbrauch?

Unter system/modules habe ich bis jetzt nur 4-5 Erweiterungen der insgesamt etwa 40 reinkopiert. Dazu sind 2 oder 3 Bundles außer dem Corezeug aktiv.

Welche sind das jeweils?


Wenn der Fehler auch komplett ohne zusätzliche Bundles/Extensions auftritt, dann würde ich das im core-bundle posten und dort auch beschreiben, dass der Speicherverbrauch beim aufbauen der Sitemap in Contao 3 mit dem selben Inhalt weitaus geringer ist, als eben in Contao 4, wo über 440 MiB verbraucht werden.

Das ist unbefriedigend. Was soll ich denn noch Höheres nehmen als einen ManagedServer?

Root Server . Aber wenn du eh schon einen Managed Server hast, warum kannst du nicht das tatsächliche memory_limit höher stellen?

[Samson1964]

Ist das sicher der Maximalverbrauch?

Das weißt Du sicher besser. Deiner Fragestellung nach zu urteilen, ist dieser Berechnung von Contao 3 nicht zu trauen.

Welche sind das jeweils?
Wenn der Fehler auch komplett ohne zusätzliche Bundles/Extensions auftritt, dann würde ich das im core-bundle posten und dort auch beschreiben, dass der Speicherverbrauch beim aufbauen der Sitemap in Contao 3 mit dem selben Inhalt weitaus geringer ist, als eben in Contao 4, wo über 440 MiB verbraucht werden.

Ich habe jetzt schon drei Testinstallationen aufgesetzt. Da ich gerade an allen drei nicht arbeiten kann/darf, werde ich noch eine vierte aufsetzen und testen.

Root Server . Aber wenn du eh schon einen Managed Server hast, warum kannst du nicht das tatsächliche memory_limit höher stellen?

Das kann wohl nur die Domainfactory-Technik einstellen. Ist ja wahrscheinlich - reine Spekulation - dasselbe Memorylimit wie beim Composer, der ja unter dem CM auch aussteigt. memory_limit in der php.ini steht auf 1000M.

[Spooky]

Wieviel Arbeitsspeicher wird dir bei diesem Managed Server Paket garantiert?

[Samson1964]

Unter Auftragsinformationen steht:

Arbeitsspeicher: 100 MB RAM
CPU-Zeit: 60 Sekunden
Skriptlaufzeit: unbegrenzt
Die oben angegebenen Werte stehen pro Skript zur Verfügung. Sofern diese für Ihre Anwendungen nicht ausreichend sind und zu einem Abbruch eines Skriptes führen, empfehlen wir zunächst Möglichkeiten zur Optimierung des Skriptes zu prüfen. Sofern dies nicht möglich sein sollte oder nicht zum Erfolg führt, kann die Skriptlaufzeit in der Serverkonfiguration deaktiviert werden. Die Werte für den Arbeitsspeicher sowie die CPU-Zeit erhöhen wir für Sie bei Bedarf gerne auf Anfrage.

Unter Serverkonfiguration steht:

SSH-Limits für Arbeitsspeicher und CPU-Zeit: deaktiviert
Durch die Deaktivierung der Checkbox können Sie festlegen, dass die vordefinierten Limits für Arbeitsspeicher (100 MB) und CPU-Zeit (60 Sekunden) für SSH aufgehoben werden. Reguläre Skriptlimits, welche beispielsweise beim Aufrufen eines Skriptes über den Browser herangezogen werden, bleiben unberührt.*
Prozesse: nicht automatisch beenden
Um eine Überlastung des Servers durch einzelne Prozesse vermeiden zu können, werden auf dem Webserver laufende Prozesse (z.B. PHP-Skripte) nach 180 Sekunden beendet. Durch die Deaktivierung der Checkbox haben Sie die Möglichkeit, dieses Prozesslimit zu deaktivieren bzw. mittels freier Eingabe ein höheres Limit zu setzen.

* Ich nehme an, damit meinen die memory_limit in der php.ini.

Die beiden Checkboxen sind beim ManagedServer normalerweise aktiviert. Ich habe das vor Jahren schon deaktiviert.

[tab]

Da sind - wenn ich das richtig verstehe - momentan für alles, was nicht über ssh bzw einen separaten Konselenprozess läuft, maximal 100 MB verfügbar. Da kann es schon mal knallen bei einer großen Seite mit vielen Inhalten. Das kann wohl durch den Service erhöht werden. Falls das das memory_limit sein sollte, kannst du es selbst erhöhen. Da das aber schon auf 1000M steht, ist es das wohl nicht sondern eher eine übergeordnete Einstellung des Servers. Da die SSH-Limits deaktiviert sind, du aber andererseits schon bei bei 441 MB an Grenzen stößt, wieviel RAM hat denn dein Server insgesamt zur Verfügung?

Edit: Hat Spooky eh schon gefragt ...

[Samson1964]

https://github.com/contao/core-bundle/issues/1157

Laut Tarif stehen bei "ManagedServer XL5" 16 GB Arbeitsspeicher zur Verfügung, wovon sicher für das Betriebssystem u.a. ein paar GB ab gehen.

[Spooky]

Welche Information bzgl. des memory_limits stimmt nun? Vielleicht solltest du da mal bei DomainFactory nachfragen, warum da ein weitere Limitierung da ist.

[Andreas]

Nur mal interessehalber, weil deine DB 1,6 GB groß ist. Welche Tabellen sind denn da so groß? Trotz der vielen Datensätze kommt mir das irgendwie seltsam hoch vor.

[Samson1964]

Das sind meistens Tabellen von eigenen Erweiterungen, z.B. rund 500 MB und über 5 Millionen Datensätze in 8 Tabellen bei einer Erweiterung mit den Karteikarten (ausgewertete Turniere) aller seit 1990 in Deutschland gemeldeten Schachspieler.

[Andreas]

Ah, ok, ich dachte schon, wie kommen denn die 1.6 GB zustande? Hast du mal mit phpMyAdmin versucht die DB zu optimieren, oder vielleicht sogar zu reparieren? (Nicht dass die kaputt wäre, nur so.)