Wie viel RAM braucht PrestaShop?

Hier gibt es zwei getrennte Zahlen, und sie zu verwechseln ist der häufigste Fehler.

PHP memory_limit (pro Request) — das ist, was PrestaShop tatsächlich pro Seitenaufruf oder Admin-Aktion verbraucht. Die offizielle PrestaShop-9-Dokumentation empfiehlt mindestens 512 MB. PrestaShop 8 kam mit 256 MB gut zurecht; der Sprung in PS 9 spiegelt den schwereren Symfony-Stack im Back Office wider. Import/Export, Modulinstallationen, Massen-Produktupdates und der Migrationsassistent brauchen dieses höhere Limit — setzen Sie es niedriger, bekommen Sie leere Bildschirme oder Fatal Errors wie Allowed memory size exhausted.

Server-RAM des Hosts — das ist der Gesamtspeicher auf VPS oder dediziertem Server, geteilt zwischen PHP-FPM-Workern, MySQL/MariaDB, Webserver, Redis oder Memcached, Cronjobs und Betriebssystem. Praktische Baselines:

• Unter 1 000 SKUs, wenig Traffic: 2 GB sind die realistische Untergrenze.
• Mittlerer Katalog (1 000 bis 20 000 SKUs), Caching aktiviert: 4 GB sind komfortabel.
• Großer Katalog (50 000+ SKUs) oder Multistore: 8 GB+ und ein dedizierter MariaDB-Tuning-Durchlauf.
• Bulk-Imports, Bildregeneration, große Migrationsjobs: zusätzlichen Puffer einplanen oder schwere Aufgaben in CLI-Cron verlagern.

Wenn der Shop langsam wirkt, ist RAM selten das Erste, was Sie reparieren sollten — beginnen Sie mit Full-Page-Cache, Redis, OPcache und einem schlankeren Theme. Die tatsächliche Reihenfolge finden Sie in unserem PrestaShop performance tuning guide.

Eine nützliche Kapazitätsprüfung ist nicht einfach memory_limit x max_children, weil nicht jeder Worker gleichzeitig das Limit erreicht, aber die Formel zeigt, ob der Host schon auf dem Papier unmöglich ist:

PHP-FPM workers x realistic worker memory + MariaDB buffer pool + Redis/OPcache + OS headroom

Zehn beschäftigte PHP-Worker mit einem 512-MB-Limit benötigen zum Beispiel mehr als einen 2-GB-VPS, sobald MariaDB einbezogen ist, auch wenn die meisten Requests weniger als das Limit nutzen. Halten Sie CLI-Limits für Bildregeneration und Imports hoch, aber vermeiden Sie, zu viele PHP-FPM-Worker auf einem kleinen Server laufen zu lassen. Wenn der Linux OOM Killer anfängt, PHP oder MariaDB zu beenden, ist es meist besser, die Workerzahl zu senken und Cache-/Datenbankdruck zu beheben, statt nur memory_limit zu erhöhen.