Das Thread-Pool-Plugin: hohe Verbindungszahlen effizient bedienen

1. Warum das klassische Thread-per-Connection-Modell an Grenzen stößt

Im Standardmodell erzeugt der Server für jede neue Verbindung einen eigenen Betriebssystem-Thread, der für die gesamte Lebensdauer der Verbindung bestehen bleibt. Bei wenigen hundert gleichzeitigen Verbindungen funktioniert das reibungslos und mit minimaler Verwaltungslast. Wächst die Anzahl gleichzeitiger Verbindungen jedoch in den vierstelligen Bereich, etwa weil mehrere PHP-FPM-Pools jeweils mit vielen Workern direkt gegen die Datenbank verbinden, ändert sich das Bild deutlich.

Jeder zusätzliche Thread bedeutet zusätzlichen Speicher für den Thread-Stack sowie zusätzlichen Aufwand für Kontextwechsel, sobald mehr Threads aktiv sind als CPU-Kerne zur Verfügung stehen. Ab einem bestimmten Punkt sinkt der tatsächliche Durchsatz sogar, weil die Threads sich gegenseitig um dieselben internen Ressourcen wie Buffer-Pool-Mutexe streiten, statt produktiv Anfragen zu bearbeiten. Mehr Verbindungen bedeuten dann nicht mehr Leistung, sondern weniger.

2. Die Grundidee des Thread-Pool-Plugins

Statt jeder Verbindung einen eigenen, dauerhaften Thread zuzuweisen, bündelt das Thread-Pool-Plugin Verbindungen in eine feste Anzahl von Thread-Gruppen. Jede Gruppe verwaltet einen begrenzten Pool an Worker-Threads, typischerweise in der Größenordnung der verfügbaren CPU-Kerne, die eingehende Anfragen aus einer Warteschlange abarbeiten, statt dass jede Verbindung dauerhaft einen eigenen Thread belegt.

Das Ergebnis ist, dass die Anzahl gleichzeitig tatsächlich ausführender Threads auf dem Server nach oben begrenzt bleibt, unabhängig davon, wie viele Verbindungen insgesamt offen sind. Eine einzelne Verbindung, die gerade auf eine Antwort vom Client wartet oder keine aktive Anfrage stellt, blockiert dabei keinen Worker-Thread, sondern gibt ihn frei für andere, tatsächlich arbeitswillige Verbindungen.

3. Gruppen und Worker-Threads konfigurieren

Die zentrale Einstellung ist thread_pool_size, welche die Anzahl der Thread-Gruppen festlegt und in der Praxis meist an die Anzahl der CPU-Kerne angelehnt wird. thread_pool_max_threads begrenzt zusätzlich die absolute Obergrenze an Worker-Threads über alle Gruppen hinweg, als Sicherheitsnetz gegen eine unkontrollierte Thread-Explosion bei ungewöhnlichem Anfrageverhalten.

Eine zu niedrig gewählte Gruppenanzahl führt dazu, dass kurze, schnelle Anfragen hinter langen, blockierenden Anfragen in derselben Warteschlange stecken bleiben. Eine zu hoch gewählte Anzahl nähert sich dagegen wieder dem Verhalten des klassischen Thread-per-Connection-Modells an und verliert den eigentlichen Vorteil der Begrenzung.

SHOW VARIABLES LIKE 'thread_pool%';

-- Typischer Startwert: Anzahl CPU-Kerne als Gruppenanzahl
SET GLOBAL thread_pool_size = 8;

4. Stall-Limit: wie das Plugin Starvation durch lange Anfragen verhindert

Ein reines Warteschlangenmodell hätte ein offensichtliches Problem: Blockiert eine lang laufende Anfrage den einzigen aktiven Worker-Thread einer Gruppe, müssten alle nachfolgenden, eigentlich schnellen Anfragen in dieser Gruppe warten, bis die lange Anfrage fertig ist. thread_pool_stall_limit löst das, indem es eine Zeitspanne definiert, nach der ein zusätzlicher Thread in einer Gruppe gestartet wird, wenn eine laufende Anfrage länger blockiert als erwartet.

Dieser Mechanismus verhindert echte Starvation, ohne dass die Gruppengröße von vornherein üppig dimensioniert werden muss. In der Praxis bedeutet ein niedrigerer Stall-Limit-Wert eine schnellere Reaktion auf blockierende Anfragen, aber auch mehr temporär zusätzlich gestartete Threads, weshalb der Wert bewusst zwischen Reaktionsgeschwindigkeit und Thread-Wachstum abgewogen werden muss.

5. Prioritäten: kurze Transaktionsanfragen vor langen Reports

Innerhalb einer Gruppe unterscheidet das Thread-Pool-Plugin zwischen hoch- und niedrigpriorisierten Anfragen. Statements, die Teil einer bereits laufenden Transaktion sind oder als kurz eingestuft werden, erhalten bevorzugten Zugriff auf freie Worker-Threads, während neue, potenziell lang laufende Anfragen wie große Report-Abfragen in eine niedrigere Prioritätsstufe einsortiert werden können.

Diese Priorisierung sorgt dafür, dass eine typische Storefront-Transaktion mit mehreren kurzen, aufeinanderfolgenden Statements nicht hinter einer einzelnen, lange laufenden Analyse-Abfrage feststeckt, selbst wenn beide Anfragetypen gleichzeitig auf denselben Server treffen. Ohne diese Unterscheidung würde ein einziger schwerer Report ausreichen, um die gefühlte Reaktionszeit des gesamten Shops kurzzeitig spürbar zu verschlechtern.

6. Thread-Pool-Aktivität überwachen

Für die laufende Überwachung liefert der Serverstatus Zähler wie Threadpool_threads für die aktuelle Gesamtzahl an Worker-Threads und Threadpool_idle_threads für die Anzahl gerade untätiger Worker. Ein dauerhaft niedriger Wert an untätigen Threads bei gleichzeitig steigender Wartezeit ist ein Hinweis darauf, dass die konfigurierte Gruppenanzahl für die aktuelle Last zu knapp bemessen ist.

Implementierungen wie das Percona-Server-Plugin ergänzen dies um detailliertere Tabellen, etwa für den aktuellen Zustand einzelner Threads und Gruppen, mit denen sich gezielt feststellen lässt, ob Anfragen tatsächlich in einer Warteschlange stehen oder der Engpass an anderer Stelle im System liegt.

SHOW GLOBAL STATUS LIKE 'Threadpool%';

-- Verbindungen gesamt vs. tatsaechlich aktiv ausführende Threads
SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW GLOBAL STATUS LIKE 'Threads_running';

7. Verhältnis zu Connection-Pooling auf Anwendungsseite

Das Thread-Pool-Plugin ersetzt kein Connection-Pooling auf Anwendungsseite oder über einen vorgeschalteten Proxy wie ProxySQL, sondern ergänzt es. Während ein vorgeschalteter Pooler die Anzahl der tatsächlich beim Server ankommenden Verbindungen von vornherein begrenzt, sorgt der Thread Pool dafür, dass selbst dann, wenn trotzdem viele tausend Verbindungen ankommen, die Serverressourcen nicht durch eine unkontrollierte Anzahl gleichzeitig aktiver Threads erschöpft werden.

Für ein Magento-Setup mit mehreren PHP-FPM-Pools, die jeweils eigene Verbindungslimits definieren, ist eine Kombination aus beidem meist am robustesten: Connection-Pooling reduziert die Anzahl der Verbindungen so weit wie möglich, und der Thread Pool fängt die verbleibende Spitzenlast kontrolliert auf, statt dass ein einzelner unerwarteter Lastanstieg den Server in die Knie zwingt.

8. Typische Stolperfallen bei der Einführung

Eine häufige Falle ist, die Gruppengröße einmalig auf Basis der zum Einführungszeitpunkt gemessenen CPU-Kernzahl zu setzen und danach nie wieder anzufassen, obwohl sich die Hardware oder das Anfragemuster über die Zeit ändert. Eine regelmäßige Überprüfung anhand der Threadpool-Statuswerte verhindert, dass eine einst passende Konfiguration Jahre später zum stillen Flaschenhals wird.

Eine zweite Falle betrifft Anwendungen mit Session-haltenden, blockierenden Transaktionen, etwa expliziten Locks, die über mehrere Statements hinweg gehalten werden. In einem zu knapp bemessenen Thread Pool können solche blockierenden Muster dazu führen, dass eine gesamte Gruppe für die Dauer der Blockade praktisch stillsteht, bis das Stall-Limit einen zusätzlichen Thread nachlegt. Eine bewusste Reduktion langer, sperrender Transaktionen bleibt deshalb auch mit Thread Pool sinnvoll.

9. Praxisempfehlung für Magento-Umgebungen mit hoher Verbindungslast

Für Magento-Installationen, bei denen mehrere Anwendungsserver oder Container gleichzeitig auf dieselbe Datenbank zugreifen, lohnt sich der Thread Pool vor allem dann, wenn Threads_connected regelmäßig deutlich über die einstellige Tausenderschwelle steigt, während Threads_running vergleichsweise niedrig bleibt. Dieses Muster zeigt, dass viele Verbindungen offen, aber nur wenige davon tatsächlich aktiv sind, genau das Szenario, in dem der Thread Pool den größten Effekt erzielt.

Vor der produktiven Einführung empfiehlt sich ein Testlauf mit realistischer, paralleler Last auf einem Staging-System, bei dem sowohl Gruppengröße als auch Stall-Limit gezielt variiert werden, statt sich auf pauschale Standardwerte zu verlassen, die für ein anderes Anfragemuster optimiert wurden.

10. Zusammenfassung

11. FAQ: Thread-Pool-Plugin: Das Wichtigste auf einen Blick