Magento-Server-Anforderungen unter Linux richtig konfigurieren

1. Warum die offizielle Anforderungsliste nur der Anfang ist

Die Magento-Systemanforderungen in der offiziellen Dokumentation lesen sich wie eine kurze Einkaufsliste: PHP 8.1 bis 8.3, MySQL 8.0 oder MariaDB 10.6, OpenSearch 2.x, Redis empfohlen, Composer 2.x. Was dort fehlt, ist die eigentliche Arbeit: Wie viele PHP-Worker braucht ein FPM-Pool bei typischer Shop-Last, welche Kernel-Limits verhindern, dass OpenSearch beim Indexieren abstuerzt, und welche Redis-Instanz uebernimmt welche Aufgabe. Wer die Anforderungsliste wortwoertlich als Installationsanleitung versteht, landet oft bei einem Server, der zwar alle Versionschecks besteht, aber unter echter Last in die Knie geht.

Der Unterschied zwischen einer bestandenen bin/magento setup:install-Ausfuehrung und einem produktionstauglichen Server liegt in Dutzenden kleinen Konfigurationsentscheidungen: PHP-Extensions mit den richtigen Kompilierungsoptionen, ein memory_limit, das zur tatsaechlichen Katalogsgroesse passt, ein OpenSearch-Cluster mit ausreichend Heap-Speicher und ein Reverse Proxy, der Magentos Full Page Cache tatsaechlich entlastet. Die folgenden Abschnitte uebersetzen jeden Punkt der offiziellen Liste in konkrete Linux-Konfiguration, mit echten Befehlen und pruefbaren Werten.

2. PHP-Version und Extensions korrekt installieren

Magento 2.4.8 verlangt PHP 8.3 (mit Support für 8.2 auf aelteren Patch-Leveln), und die Liste der Pflicht-Extensions ist laenger als viele Standardinstallationen mitbringen: bcmath, ctype, curl, dom, gd oder imagick, intl, mbstring, openssl, pdo_mysql, simplexml, soap, sodium, xsl und zip. Auf Debian/Ubuntu-Systemen mit dem Ondrej-Sury-PPA lassen sich alle Pakete in einem Rutsch installieren, doch sodium und intl werden erfahrungsgemaess am haeufigsten vergessen, weil sie in minimalen PHP-Images standardmaessig fehlen.

Nach der Installation lohnt sich immer eine Gegenprobe mit php -m gegen die Anforderungsliste, statt sich auf das Setup-Wizard-Ergebnis zu verlassen, denn der Wizard bricht teils erst mitten im Installationsprozess ab. Auch die PHP-CLI und der PHP-FPM-Pool müssen dieselben Extensions laden: Ein haeufiger Fehler ist eine php.ini für CLI, die von der FPM-Konfiguration abweicht, wodurch Cronjobs mit anderen Werten laufen als der Webserver. Composer selbst benoetigt zusaetzlich Git und Zip auf Betriebssystemebene, nicht nur als PHP-Extension.

#!/usr/bin/env bash
# Install PHP 8.3 and all required extensions for Magento 2.4.8 on Ubuntu
set -euo pipefail

sudo add-apt-repository -y ppa:ondrej/php
sudo apt-get update

sudo apt-get install -y \
  php8.3-fpm php8.3-cli \
  php8.3-bcmath php8.3-curl php8.3-gd php8.3-intl \
  php8.3-mbstring php8.3-mysql php8.3-soap php8.3-sodium \
  php8.3-xml php8.3-xsl php8.3-zip php8.3-opcache php8.3-igbinary \
  php8.3-redis php8.3-imagick

# Verify all Magento-required extensions are actually loaded
required=(bcmath ctype curl dom gd intl mbstring openssl pdo_mysql simplexml soap sodium xsl zip)
for ext in "${required[@]}"; do
  php -m | grep -qi "^${ext}$" || echo "[MISSING] ${ext}"
done

php -v

3. memory_limit, OPcache und PHP-FPM-Tuning

Magento empfiehlt offiziell mindestens 2 GB memory_limit, doch dieser Wert reicht bei bin/magento indexer:reindex oder Composer-Operationen auf groesseren Katalogen nicht aus. In der Praxis setzen wir memory_limit = 4G für CLI-Kontexte und lassen den Wert für den FPM-Pool bewusst niedriger, da hier viele parallele Worker gleichzeitig Speicher belegen und ein zu hoher Wert den Server bei einem Traffic-Spike in Swap treiben kann. Getrennte php.ini-Overrides pro SAPI (/etc/php/8.3/cli/conf.d/ versus /etc/php/8.3/fpm/conf.d/) sind hier das korrekte Muster, nicht eine globale Datei für beide Kontexte.

OPcache ist für Magento nicht optional, sondern Pflicht: Ohne kompilierten Bytecode-Cache dauert jeder Request durch die vielen tausend Klassen des Frameworks spuerbar laenger. opcache.memory_consumption=512 und opcache.max_accelerated_files=60000 sind realistische Startwerte für einen mittelgrossen Katalog, wobei max_accelerated_files immer über der tatsaechlichen PHP-Dateianzahl liegen muss, sonst rotiert der Cache staendig neu. Beim PHP-FPM-Pool bestimmt pm.max_children zusammen mit dem verfuegbaren RAM die maximale gleichzeitige Request-Last: Faustregel ist verfuegbarer RAM geteilt durch den durchschnittlichen Speicherverbrauch eines PHP-Prozesses unter Last, typischerweise 80 bis 150 MB pro Worker bei Magento.

; /etc/php/8.3/fpm/pool.d/magento.conf - PHP-FPM pool tuned for Magento 2
[magento]
user = magento
group = magento
listen = /run/php/php8.3-fpm-magento.sock
listen.owner = www-data
listen.group = www-data

pm = dynamic
pm.max_children = 40
pm.start_servers = 8
pm.min_spare_servers = 6
pm.max_spare_servers = 12
pm.max_requests = 500

; FPM workers stay below CLI limit to avoid pushing the host into swap
php_admin_value[memory_limit] = 1G
php_admin_value[max_execution_time] = 120
php_admin_value[upload_max_filesize] = 64M
php_admin_value[post_max_size] = 64M

; opcache tuning - shared across CLI and FPM via /etc/php/8.3/conf.d/10-opcache.ini
; opcache.memory_consumption=512
; opcache.max_accelerated_files=60000
; opcache.validate_timestamps=0  ; production only, requires manual reload on deploy

4. Datenbank: MySQL/MariaDB-Konfiguration für Magento

Magento 2.4.8 unterstuetzt MySQL 8.0.x und MariaDB 10.6 LTS, wobei die InnoDB-Engine und die Zeichensatzkonfiguration utf8mb4 zwingend vorausgesetzt werden. Ein haeufig uebersehener Konfigurationswert ist innodb_buffer_pool_size, der auf einem dedizierten Datenbankserver etwa 60 bis 70 Prozent des verfuegbaren RAM betragen sollte, da Magentos EAV-Datenmodell viele kleine Joins erzeugt, die stark vom InnoDB-Bufferpool profitieren. Ohne ausreichenden Bufferpool zeigt sich das Problem meist zuerst bei der Kategorieseiten-Performance, lange bevor es im Checkout auffaellt.

max_connections muss zur Anzahl der PHP-FPM-Worker plus Cron-Prozessen plus Admin-Sessions passen, da Magento pro aktivem Request typischerweise eine eigene Datenbankverbindung haelt. Ein Wert von 40 pm.max_children plus Cron-Parallelitaet plus Reserve landet schnell bei max_connections = 200 oder mehr. Zusaetzlich sollte sql_mode keine der von Magento explizit inkompatiblen Strict-Modes wie STRICT_TRANS_TABLES zusammen mit bestimmten Legacy-Modulen aktivieren, ohne vorher die Kompatibilitaet mit allen installierten Extensions geprueft zu haben.

5. OpenSearch/Elasticsearch als Suchindex einrichten

Seit Magento 2.4.4 ist ein externer Suchindex über OpenSearch oder Elasticsearch Pflicht, MySQL-basierte Suche wird nicht mehr unterstuetzt. Magento 2.4.8 verlangt konkret OpenSearch 2.5 bis 2.19 oder Elasticsearch 8.11, wobei OpenSearch inzwischen die empfohlene Variante ist, da Elastic die Lizenz mehrfach geaendert hat. Der haeufigste Fehler beim Erststart: vm.max_map_count ist auf Standard-Linux-Systemen mit 65530 zu niedrig für die von OpenSearch verwendeten mmap-basierten Indizes und muss dauerhaft auf mindestens 262144 gesetzt werden, sonst crasht der Service beim Hochfahren mit einer kryptischen Fehlermeldung über virtuellen Speicher.

Der JVM-Heap von OpenSearch sollte nie mehr als 50 Prozent des verfuegbaren RAM und niemals mehr als 31 GB betragen, da die JVM oberhalb dieser Grenze die Compressed-Oops-Optimierung verliert und die effektive Heap-Nutzung ineffizienter wird. bin/magento indexer:reindex catalogsearch_fulltext ist der Befehl, mit dem sich nach der Konfiguration pruefen laesst, ob die Verbindung tatsaechlich steht, bevor der erste echte Produktimport laeuft.

# /etc/opensearch/opensearch.yml - single-node setup for a Magento store
cluster.name: magento-search
node.name: magento-search-01
network.host: 127.0.0.1
http.port: 9200
discovery.type: single-node

# Security plugin disabled for internal-only access behind firewall
plugins.security.disabled: true

# Heap size set separately in jvm.options: -Xms4g -Xmx4g (never above 50% of RAM)
bootstrap.memory_lock: true

#!/usr/bin/env bash
# Persist vm.max_map_count so OpenSearch survives a reboot
set -euo pipefail

echo "vm.max_map_count=262144" | sudo tee /etc/sysctl.d/99-opensearch.conf
sudo sysctl -p /etc/sysctl.d/99-opensearch.conf

# Connect Magento to the local OpenSearch instance
bin/magento config:set catalog/search/engine opensearch
bin/magento config:set catalog/search/opensearch_server_hostname 127.0.0.1
bin/magento config:set catalog/search/opensearch_server_port 9200
bin/magento indexer:reindex catalogsearch_fulltext

6. Redis für Cache, Session und Full Page Cache

Magento kann Backend-Cache, Sessions und Full Page Cache alle drei über Redis abwickeln, doch die offizielle Empfehlung, dafuer separate Redis-Datenbanken oder besser separate Instanzen zu nutzen, wird in der Praxis oft ignoriert. Der Grund für die Trennung: Ein FLUSHALL oder ein Memory-Eviction-Ereignis in der Session-Datenbank darf niemals gleichzeitig den Full Page Cache leeren, sonst verlieren alle aktiven Nutzer gleichzeitig ihre Warenkoerbe und der Server bekommt einen Cache-Miss-Sturm auf einmal. Redis 7.x wird von Magento 2.4.8 offiziell unterstuetzt, wobei maxmemory-policy allkeys-lru für Cache-Instanzen sinnvoll ist, für die Session-Instanz dagegen noeviction, damit aktive Sessions nie stillschweigend geloescht werden.

Die PHP-Extension redis (nicht die reine predis-Bibliothek) sollte installiert sein, da sie deutlich performanter serialisiert, besonders in Kombination mit igbinary als Serialisierungsformat. In env.php wird jede Redis-Rolle mit eigener database-Nummer und eigenem port oder eigener Instanz konfiguriert, was Monitoring und Kapazitaetsplanung deutlich vereinfacht, weil sich Cache-Hitrate und Session-Last getrennt beobachten lassen.

#!/usr/bin/env bash
# Configure three separate Redis roles for Magento via bin/magento CLI
set -euo pipefail

# Backend cache (database 0)
bin/magento setup:config:set \
  --cache-backend=redis \
  --cache-backend-redis-server=127.0.0.1 \
  --cache-backend-redis-db=0 \
  --cache-backend-redis-port=6379

# Full Page Cache (database 1) - separate from backend cache on purpose
bin/magento setup:config:set \
  --page-cache=redis \
  --page-cache-redis-server=127.0.0.1 \
  --page-cache-redis-db=1 \
  --page-cache-redis-port=6379

# Sessions (database 2) - noeviction policy required, never share with cache
bin/magento setup:config:set \
  --session-save=redis \
  --session-save-redis-host=127.0.0.1 \
  --session-save-redis-db=2 \
  --session-save-redis-port=6379

7. Varnish als HTTP-Accelerator vor Magento

Magento liefert einen eingebauten Full Page Cache, doch dieser laeuft weiterhin durch den PHP-Prozess und ist damit deutlich langsamer als ein davorgeschalteter Varnish-Reverse-Proxy, der gecachte Seiten direkt aus dem RAM ausliefert, ohne PHP ueberhaupt zu starten. Magento 2.4.8 unterstuetzt offiziell Varnish 7.5 und 7.6, und die von Magento generierte VCL-Konfiguration (bin/magento varnish:vcl:generate) deckt bereits die wichtigsten Header-Regeln für Cache-Invalidierung ab, muss aber immer an die tatsaechliche Domain- und Backend-Konfiguration angepasst werden.

Ein zentraler Stolperstein: Der X-Magento-Cache-Debug-Header muss in der Produktion deaktiviert oder zumindest nicht oeffentlich sichtbar sein, während er während der Einrichtung unverzichtbar ist, um HIT/MISS-Verhalten pro Request zu verifizieren. Ebenso wichtig ist, dass der X-Forwarded-For-Header korrekt durchgereicht wird, sonst protokolliert Magento für alle Besucher dieselbe Varnish-IP, was sowohl Analytics als auch IP-basierte Sicherheitsregeln unbrauchbar macht.

#!/usr/bin/env bash
# Generate and deploy Varnish VCL for Magento 2.4.8
set -euo pipefail

bin/magento config:set system/full_page_cache/caching_application 2
bin/magento config:set system/full_page_cache/varnish/access_list "localhost,127.0.0.1"
bin/magento config:set system/full_page_cache/varnish/backend_host 127.0.0.1
bin/magento config:set system/full_page_cache/varnish/backend_port 8080

bin/magento varnish:vcl:generate --export-version=7.5 > /etc/varnish/default.vcl

# Verify HIT/MISS behaviour before removing the debug header in production
curl -sI https://shop.example.com/ | grep -i x-magento-cache

sudo systemctl restart varnish

8. Pre-Flight-Checkliste vor dem Deployment

Bevor bin/magento setup:install oder ein Produktions-Deployment ueberhaupt startet, lohnt sich eine feste Checkliste, die jeden Anforderungspunkt systematisch abhakt, statt sich auf das Bauchgefuehl zu verlassen. Diese Liste hat sich in der Praxis bewaehrt, weil sie genau die Stellen abdeckt, an denen Setups am haeufigsten scheitern: PHP-Extensions, Speicherlimits, Datenbankverbindung, Suchindex-Erreichbarkeit und Dateisystem-Berechtigungen für var/, pub/media/ und generated/.

Ein oft unterschaetzter Punkt ist die Dateisystem-Performance: Magento schreibt während eines Deployments zehntausende kleine Dateien in generated/code/ und pub/static/, und ein langsames Netzwerk-Dateisystem wie NFS ohne passende Mount-Optionen kann ein Deployment von wenigen Minuten auf mehr als eine Stunde verlaengern. Die Checkliste sollte deshalb auch einen kurzen dd-Schreibtest auf dem Zielverzeichnis enthalten, um grobe I/O-Probleme fruehzeitig zu erkennen, bevor sie in einem laufenden Deployment sichtbar werden.

9. Haeufige Requirement-Mismatch-Fehler beim Setup

Der wohl haeufigste Fehler beim Magento-Setup ist eine falsche Zeichensatzkonfiguration der Datenbank: Wird die Datenbank mit utf8 statt utf8mb4 angelegt, schlaegt die Installation erst bei bestimmten Tabellen mit langen Indizes fehl, oft weit nach dem ersten erfolgreichen Schritt. Ein zweiter Klassiker ist eine PHP-Version, die zwar formal im unterstuetzten Bereich liegt, aber als veraltetes Patch-Release bekannte Inkompatibilitaeten mit Magentos Composer-Dependencies hat, was sich erst bei composer install mit kryptischen Versions-Constraint-Fehlern zeigt.

Ein dritter wiederkehrender Fehler betrifft Dateisystem-Berechtigungen: Wird var/, pub/media/ oder generated/ nicht dem PHP-FPM-Benutzer gehoerend angelegt, schlagen Schreibvorgaenge erst beim ersten Cache-Flush oder Media-Upload fehl, nicht beim Setup selbst. Und ein vierter, besonders tueckischer Fehler: OpenSearch laeuft zwar, ist aber über einen falschen Port oder eine falsche Firewall-Regel nicht erreichbar, sodass setup:install zwar durchlaeuft, aber die Suche im laufenden Shop leere Ergebnisse liefert, bis jemand das Firewall-Log prueft.

{
  "_comment": "app/etc/env.php excerpt - common mismatch: db table_prefix and utf8mb4 charset",
  "db": {
    "connection": {
      "default": {
        "host": "127.0.0.1",
        "dbname": "magento",
        "username": "magento",
        "password": "REPLACE_ME",
        "model": "mysql4",
        "engine": "innodb",
        "initStatements": "SET NAMES utf8mb4;",
        "active": "1",
        "driver_options": {
          "1013": "utf8mb4"
        }
      }
    }
  },
  "cache_types": {
    "config": 1,
    "layout": 1,
    "block_html": 1,
    "full_page": 1
  }
}

10. Zusammenfassung

Die Magento-Server-Anforderungen unter Linux sind kein einmaliger Versionscheck, sondern ein Zusammenspiel aus PHP-Extensions, Speicherlimits, Datenbankkonfiguration, Suchindex und Caching-Diensten, das nur als Ganzes funktioniert. PHP 8.3 mit allen Pflicht-Extensions und getrennten CLI-/FPM-Konfigurationen bildet das Fundament, memory_limit und OPcache bestimmen die Performance unter Last, und OpenSearch mit korrektem vm.max_map_count verhindert Crashes beim Indexieren. Redis in drei getrennten Rollen und Varnish als vorgeschalteter Accelerator entlasten den PHP-Prozess spuerbar.

Der größte Hebel liegt in der systematischen Pre-Flight-Checkliste vor jedem Deployment: Wer PHP-Extensions, Zeichensatz, Dateisystem-Berechtigungen und Suchindex-Erreichbarkeit vor dem ersten setup:install prueft, vermeidet die typischen Requirement-Mismatch-Fehler, die sonst erst mitten im Betrieb sichtbar werden. Eine einmal aufgesetzte Checkliste laesst sich für jedes weitere Deployment wiederverwenden und automatisieren.

11. FAQ: Magento-Server-Anforderungen unter Linux