Speicher- und Laufzeitfehler in PrestaShop: memory_limit und Co.

Sie starten einen Produktimport, und mittendrin bleibt er mit einer weißen Seite stehen. Eine geplante Aufgabe, die den Bestand synchronisiert, ist seit Wochen nicht fertig geworden. Der Export der Bestellungen funktioniert für einen Monat, aber nicht für ein Jahr. Im Fehlerprotokoll erscheinen Meldungen wie Allowed memory size of ... bytes exhausted oder Maximum execution time of ... seconds exceeded.

Das sind die beiden häufigsten Limits von PHP, und es gibt mehr davon, als man denkt. Sehen wir uns an, welche es sind, wo sie eingestellt werden und wann es sinnvoll ist, sie anzuheben.

Die beteiligten Limits

memory_limit

Der maximale Arbeitsspeicher, den ein PHP-Prozess nutzen darf. Überschreitet eine Anfrage ihn, bricht PHP sie mit einem fatalen Fehler ab: Allowed memory size exhausted. Im Shop zeigt sich das als weiße Seite oder Fehler 500.

max_execution_time

Die maximale Zeit in Sekunden, die ein Skript laufen darf. Wird sie überschritten, stoppt PHP es: Maximum execution time exceeded. Achtung: Unter Linux zählt dieser Zähler nicht die Zeit, die das Skript auf die Datenbank oder eine externe API wartet, sondern nur die eigene Ausführungszeit.

Die Limits außerhalb von PHP

Auch wenn PHP nicht abgebrochen hat, kann die Anfrage vorher an anderer Stelle sterben:

• Der PHP-Prozessmanager (PHP-FPM) hat eine eigene maximale Zeit pro Anfrage.
• Der Webserver oder der Proxy (Apache, Nginx, ein Load Balancer oder ein CDN) schließen die Verbindung, wenn sie innerhalb einer bestimmten Zeit keine Antwort erhalten. Der Kunde sieht einen Fehler 502 oder 504, während das Skript dahinter womöglich weiterläuft.
• Die Datenbank kann inaktive Verbindungen oder zu lange Abfragen beenden.
• max_input_vars, das weder Speicher noch Zeit betrifft, aber ähnliche Symptome zeigt: Es begrenzt, wie viele Felder ein Formular annimmt. Eine Produktseite mit vielen Kombinationen oder eine Übersetzungsseite speichert dann womöglich nur einen Teil der Daten, ohne einen sichtbaren Fehler anzuzeigen.

Wo sie eingestellt werden

Das hängt vom Hosting ab:

• Im Hosting-Panel, im Bereich PHP-Konfiguration: der häufigste Fall.
• In einer Datei php.ini oder .user.ini im Stammverzeichnis der Website, sofern der Hoster das erlaubt.
• In der Serverkonfiguration, wenn Sie einen VPS oder dedizierten Server haben.

Um zu wissen, welche Werte der Shop tatsächlich hat, verlassen Sie sich nicht auf die Angaben im Panel: Prüfen Sie es in den Serverinformationen des Back-Office (Erweiterte Einstellungen → Informationen) oder mit einer temporären Seite, die die PHP-Konfiguration anzeigt, und löschen Sie diese danach.

Wo sie in PrestaShop auftreten

• Große CSV-Importe, vor allem mit Bildern, die während des Imports von einer URL heruntergeladen werden.
• Neuerzeugung von Miniaturansichten in Katalogen mit vielen oder sehr großen Fotos.
• Geplante Aufgaben von Modulen, die mit einem ERP, einem Lieferanten oder einem Marktplatz synchronisieren.
• Exporte von Bestellungen, Kunden oder Produkten über lange Zeiträume.
• PDF-Erzeugung mit vielen Rechnungen auf einmal.
• Cache leeren oder den Symfony-Container in PrestaShop 8 und 9 neu kompilieren, was auf einen Schlag viel Speicher braucht.
• Bestimmte Seiten: eine Kategorie mit Tausenden Produkten ohne Seitenaufteilung, ein Produkt mit Hunderten Kombinationen, eine Bestellansicht mit vielen Positionen.

Wann Sie das Limit anheben sollten und wann nicht

memory_limit oder max_execution_time anzuheben ist vernünftig, wenn der Prozess berechtigterweise groß ist und nur gelegentlich läuft: ein Erstimport, eine Migration, eine vollständige Neuerzeugung. PrestaShop verlangt von sich aus ein großzügiges Speicherminimum, und viele Hoster liefern Werte, die unter dem Bedarf des Shops liegen.

Wenn Sie aber jedes Mal mehr brauchen, liegt das Problem woanders:

• Ein Prozess, der alles in den Speicher lädt (alle Produkte, alle Bestellungen), statt in Stapeln zu arbeiten. Mit dem heutigen Katalog passt es noch, mit dem vom nächsten Jahr nicht mehr.
• Eine Schleife, die nicht endet oder wegen eines Modulfehlers immer wieder dasselbe verarbeitet.
• Abfragen ohne Index auf gewachsenen Tabellen, die immer länger dauern.
• Langsame Aufrufe externer APIs im selben Prozess, einer pro Produkt.

Wenn ein riesiges Limit eine normale Shopseite „repariert“, etwa eine Kategorie oder eine Produktseite, ist sie nicht repariert: Diese Seite verbraucht Ressourcen, die sie nicht verbrauchen sollte, und unter Last wird sie den Server lahmlegen.

So diagnostizieren Sie es

1. Lesen Sie die vollständige Meldung im PHP-Fehlerprotokoll: Sie nennt die Datei und die Zeile, in der Speicher oder Zeit erschöpft waren. Manchmal ist es die Zeile eines bestimmten Moduls, manchmal eine Core-Funktion, die von einem Modul aufgerufen wird.
2. Unterscheiden Sie Web und Terminal: Tritt der Fehler beim Aufruf einer URL auf oder beim Start eines Skripts über die Konsole? Beide haben ihre eigenen Limits.
3. Sehen Sie sich den Antwortcode an: Ein 500 ist meist PHP, ein 502 oder 504 der Webserver oder Proxy, der nicht mehr warten wollte.
4. Reproduzieren Sie ihn auf einer Kopie mit aktiviertem Debug-Modus von PrestaShop, der den Fehler auf dem Bildschirm statt einer weißen Seite anzeigt.
5. Prüfen Sie, ob er mit den Daten wächst: Scheitert es bei einem Jahr und nicht bei einem Monat, arbeitet der Prozess nicht in Stapeln.

Bewährte Vorgehensweisen für lange Prozesse

• Starten Sie aufwendige Aufgaben über das Terminal statt über den Aufruf einer URL, wann immer das Modul es erlaubt.
• Teilen Sie große Importe in kleinere Dateien auf.
• Planen Sie aufwendige Aufgaben außerhalb der Hauptverkehrszeiten und vermeiden Sie, dass zwei gleichzeitig laufen.
• Nutzen Sie Module, die in Stapeln arbeiten und dort weitermachen, wo sie bei einer Unterbrechung aufgehört haben.
• Halten Sie PrestaShop, PHP und Module aktuell: Moderne PHP-Versionen verbrauchen weniger Speicher und sind mit demselben Code schneller.

So lösen Sie es in PrestaShop

RKR Sentinel meldet Ihnen per Telegram, wenn der Shop Fehler wegen erschöpften Speichers, Zeitüberschreitungen, fatale Fehler oder 500-Antworten liefert, mit Meldung, Datei und Zeile, einem Codeausschnitt, dem Stacktrace, der URL und den Versionen, ohne dass Sie im Live-Shop den Debug-Modus aktivieren müssen. Jeder Fehler wird anhand seines Fingerabdrucks gruppiert, damit Wiederholungen den Chat nicht fluten. Liegt das Problem in einem Prozess, der so umgebaut werden muss, dass er in Stapeln arbeitet, oder in Serverlimits, von denen Sie nicht wissen, wo sie eingestellt werden, diagnostizieren wir es mit einem Support-Stundenpaket von Rekire auf einer Kopie und beheben es.