Shopware Queue und Worker dauerhaft betreiben

Zuletzt geprüft 28. Juli 2026 Shopware

Shopware 6 erledigt Mails, Indexierung, Import/Export und geplante Aufgaben über die Message Queue . Ohne eigene Worker arbeitet die Queue nur, solange das Admin im Browser geöffnet ist — für den Livebetrieb ist das zu wenig. Dieser Artikel zeigt zwei Wege zu dauerhaften Workern, beide ohne root-Rechte: den Schnellstart per Cronjob und die komfortable systemd-Variante.

Voraussetzungen

SSH-Zugang für Einrichtung und Tests — siehe SSH-Zugang einrichten. Die Cronjob-Variante lässt sich auch komplett im Panel anlegen.
Der Pfad zu deiner Shopware-Installation und die passende PHP-Binary deiner Domain — siehe PHP-Version auf der Shell.

Wie die Queue arbeitet

Shopware legt Aufträge in zwei Transports ab: async und low_priority. Gespeichert wird standardmäßig in der Datenbank (Tabelle messenger_messages). Verarbeitet wird von zwei Prozess-Typen:

messenger:consume — der eigentliche Worker, der die Queue abarbeitet.
scheduled-task:run — der Scheduler, der fällige geplante Aufgaben (Sitemap, Aufräum-Jobs, …) als Aufträge in die Queue legt.

Ab Werk übernimmt der Admin-Worker beides per Browser-Polling — aber eben nur, solange jemand im Admin eingeloggt ist. Deshalb richtest du zuerst dauerhafte Worker ein (Variante 1 oder 2) und schaltest den Admin-Worker danach ab.

Du willst dich gar nicht selbst darum kümmern? Mit Rent-an-Admin übernehmen wir Einrichtung und laufenden Betrieb der Worker als Teil der Administration.

Variante 1: Schnellstart per Cronjob

Funktioniert auf allen Tarifen, braucht kein SSH-Wissen und heilt sich selbst: Der Worker läuft knapp fünf Minuten, beendet sich sauber, der nächste Cron-Start übernimmt. Stürzt ein Prozess ab, ist die Lücke maximal fünf Minuten.

Leg zwei Cronjobs mit dem Zeitplan */5 * * * * an — im Panel unter Geplante Aufgaben (Plesk) bzw. Cronjobs (cPanel), siehe Cronjob einrichten:

*/5 * * * * flock -n "$HOME/.sw-worker.lock" /opt/plesk/php/8.3/bin/php /var/www/vhosts/beispiel.de/httpdocs/bin/console messenger:consume async low_priority --time-limit=290 --memory-limit=512M
*/5 * * * * flock -n "$HOME/.sw-scheduler.lock" /opt/plesk/php/8.3/bin/php /var/www/vhosts/beispiel.de/httpdocs/bin/console scheduled-task:run --time-limit=290 --memory-limit=512M

Pfad zur PHP-Binary und zur Installation an deine Umgebung anpassen.

Warte fünf Minuten und prüf per SSH, ob beide Prozesse laufen:
Terminal-Fenster
```
ps aux | grep console
```
Schalte danach den Admin-Worker ab — siehe unten.

Die Flags im Einzelnen: flock -n verhindert Doppelstarts, solange der vorherige Lauf noch aktiv ist. --time-limit=290 beendet den Prozess nach knapp fünf Minuten, passend zum Cron-Takt. --memory-limit=512M startet den Worker neu, bevor ein PHP-Prozess zu viel Speicher ansammelt — beides von Shopware empfohlene Schutzmechanismen gegen Langläufer-Lecks.

Variante 2: systemd User-Units auf dem Managed Server

Auf unseren Managed Servern (AlmaLinux, ohne Shell-Einschränkungen) kannst du Worker als systemd User-Services betreiben — echte Dienste mit automatischem Neustart und Logs, komplett in deiner Hand und ohne root. Einzige Voraussetzung: Wir aktivieren einmalig das Lingering für deinen Benutzer.

Eröffne ein Ticket mit der Bitte um Linger-Freischaltung für deinen SSH-Benutzer. Das ist eine einmalige Einstellung — danach verwaltest du deine Services selbst.
Leg die Unit-Datei ~/.config/systemd/user/shopware-worker.service an:
```
[Unit]
Description=Shopware Queue-Worker

[Service]
ExecStart=/opt/plesk/php/8.3/bin/php %h/httpdocs/bin/console messenger:consume async low_priority --time-limit=3600 --memory-limit=512M
Restart=always
RestartSec=5

[Install]
WantedBy=default.target
```
%h steht für dein Home-Verzeichnis; Pfade wieder anpassen. Das Zusammenspiel aus --time-limit=3600 und Restart=always recycelt den Worker stündlich — frischer Prozess statt Speicher-Leck.
Leg analog shopware-scheduler.service an — gleicher Aufbau, als ExecStart-Befehl scheduled-task:run statt messenger:consume async low_priority.

Aktiviere und starte beide Dienste:

systemctl --user daemon-reload
systemctl --user enable --now shopware-worker shopware-scheduler

Prüf Status und Logs:

systemctl --user status shopware-worker
journalctl --user -u shopware-worker -f

Schalte danach den Admin-Worker ab — nächster Abschnitt.

Admin-Worker abschalten

Erst abschalten, wenn Variante 1 oder 2 nachweislich läuft — sonst steht die Queue komplett still.

Leg die Datei config/packages/shopware.yaml in deiner Installation an (oder ergänze sie):
```
shopware:
    admin_worker:
        enable_admin_worker: false
```
Leere den Cache: bin/console cache:clear — siehe Shopware-Cache leeren.

Reicht ein Worker — oder besser mehrere?

Für die meisten Shops reicht ein messenger:consume-Prozess, der beide Transports abarbeitet. Wichtig ist, async und low_priority im Befehl zu nennen — fehlt der zweite, bleiben nachrangige Aufträge dauerhaft liegen.

Mehr Worker lohnen erst bei spürbarem Rückstau: große Importe, Thumbnail-Generierung, Voll-Indexierung. Anzeichen ist eine dauerhaft wachsende messenger_messages-Tabelle bzw. ein voller Queue-Monitor im Admin. Dann startest du zwei bis drei Consumer parallel — bei der Cron-Variante als zusätzliche Zeilen mit jeweils eigener Lock-Datei, bei systemd als Kopien der Unit (shopware-worker2.service). Deutlich mehr als drei bringt mit dem Datenbank-Transport wenig: Die parallelen Consumer konkurrieren um dieselbe Tabelle. Wächst dein Shop in diese Region, sprich uns an — dann ist ein dedizierter Message-Broker das passendere Werkzeug.

Wenn etwas schiefläuft

Mails gehen erst raus, wenn jemand das Admin öffnet

Der Shop läuft noch im Admin-Worker-Betrieb — die Queue arbeitet nur bei geöffnetem Backend.

Lösung: Variante 1 oder 2 einrichten, danach den Admin-Worker abschalten.

Die Tabelle `messenger_messages` wächst immer weiter

Es läuft kein Worker, zu wenige — oder der Befehl konsumiert nur async und lässt low_priority liegen.

Lösung: Prozesse prüfen (ps aux | grep console bzw. systemctl --user status shopware-worker), beide Transports im Befehl nennen, bei anhaltendem Rückstau einen zweiten Consumer starten.

Der Worker bricht mit `Allowed memory size exhausted` ab

Das PHP-CLI-Memory-Limit liegt unter dem Wert von --memory-limit — der Worker stirbt hart, statt sauber neu zu starten.

Lösung: --memory-limit unterhalb des PHP-Limits wählen oder das CLI-Limit anheben (php -d memory_limit=768M …). Der Flag-Wert muss immer der kleinere sein.

Geplante Aufgaben laufen nicht, obwohl der Worker aktiv ist

messenger:consume verarbeitet nur, was in der Queue liegt. Fehlt der Scheduler-Prozess, legt niemand die fälligen Aufgaben hinein.

Lösung: Den zweiten Prozess mit scheduled-task:run einrichten — als Cronjob oder eigene User-Unit, siehe oben.

Du kommst nicht weiter?

Wenn Worker oder Scheduler nicht anlaufen: Ticket im Kundencenter öffnen. Nenn die gewählte Variante, deine Shopware-Version und den Befehl, den du eingerichtet hast — wir schauen direkt auf dem Server nach.