Open-Source-Datenbankserver führt Thread-Pooling in 26.7.0 und 9.7.2 ein
Der Datenbank-Thread-Pool ist in der kostenlosen Community-Edition des Open-Source-Datenbankservers ab der Juli-Version 26.7.0 und 9.7.2 verfügbar. Percona-Softwareentwickler Bogdan Degtyariov schreibt in einem Beitrag vom 5. Oktober 2026, dass das offizielle Thread-Pool-Plugin des Servers zuvor nur zahlenden Kunden der Enterprise-Edition desselben Datenbankservers vorbehalten war. Die wichtigsten kostenlosen Alternativen mit Thread-Pooling waren Perconas Datenbankserver, der es als Plugin auslieferte, ein Community-Fork derselben Engine mit integriertem Thread-Pooling sowie ein Drittanbieter-Plugin auf GitHub. Dieser erste Teil von Degtyariovs Analyse behandelt, was Thread-Pooling ist und wie Perconas Datenbankserver es implementiert; ein Leistungsvergleich zwischen Perconas Datenbankserver und dem Open-Source-Datenbankserver folgt in Teil 2.
Thread-Pooling ist eine Technik, die eine feste Anzahl vorab erstellter Threads wiederverwendet, um mehrere Client-Verbindungen zu bedienen und Anweisungen innerhalb einer Datenbank auszuführen. In der Standardkonfiguration des Open-Source-Datenbankservers, genannt One-Thread-per-Connection, erstellt der Server bei jeder Client-Verbindung einen dedizierten Thread, führt die Abfragen dieses Clients aus und zerstört den Thread anschließend. Wenn die Anzahl der Verbindungen sehr groß wird, führt diese Standardmethode zu einem erheblichen Leistungsabfall, da das Erstellen, Zerstören und ständige Wechseln zwischen Tausenden von Threads – ein Prozess namens Context Switching – Systemressourcen verschwendet und Konflikte verursacht, da viele Prozesse um dieselbe CPU und denselben Speicher konkurrieren. Perconas Vadim Tkachenko hat in einem separaten Beitrag eine Analogie zur Verkehrssteuerung verwendet, um Thread-Pooling zu erklären, und die Dokumentation von Percona behandelt es weiter. Degtyariov fügt eine klare Warnung hinzu: Ein Thread-Pool ist kein universeller Datenbank-Booster. Es ist ein fortgeschrittenes Werkzeug, das mit vollem Verständnis der Arbeitslast eingesetzt werden muss; andernfalls können die Ergebnisse alles andere als perfekt sein.
Thread-Pooling organisiert die Arbeit in Thread-Gruppen. Jede Gruppe ist einem bestimmten CPU-Kern zugeordnet, sodass die Anzahl der Gruppen oft der Anzahl der physischen oder logischen Kerne entspricht. Eingehende Client-Verbindungen werden gleichmäßig auf diese Gruppen verteilt, und zwar mit einer Round-Robin-Methode, d. h. jede neue Verbindung wird der Reihe nach an die nächste Gruppe gesendet. Innerhalb jeder Gruppe überwacht ein Listener-Thread eingehende Abfragen und legt sie entweder in eine Warteschlange mit hoher Priorität, z. B. Abfragen innerhalb einer aktiven Transaktion, oder in eine normale Warteschlange mit niedriger Priorität. Worker-Threads nehmen dann Abfragen aus den Warteschlangen entgegen, wobei sie immer zuerst Elemente mit hoher Priorität bearbeiten, führen sie aus und warten auf die nächste Anforderung, anstatt sich zu beenden. Diese Wiederverwendung eliminiert den Aufwand für das Erstellen und Zerstören eines Threads für jede Verbindung.
Der von Degtyariov beschriebene Benchmark variiert mehrere Thread-Pool-Einstellungen. Die Basislinie verwendet thread_handling=one-thread-per-connection, während gepoolte Läufe thread_handling=pool-of-threads verwenden. Der Parameter thread_pool_size wird mit 10, 20, 40, 80, 120 und 160 getestet; der Autor merkt an, dass auch ein Wert von 5 getestet wurde, die Leistung jedoch unbefriedigend war und er nicht aufgeführt wird. Ein zweites Parameterpaar, thread_pool_max_threads / thread_pool_max_active_query_threads, ist auf 12000 als maximale Anzahl von Threads im Pool festgelegt. Ein drittes Paar, thread_pool_oversubscribe / thread_pool_query_threads_per_group, variiert die Werte 2, 3 und 4, die festlegen, wie viele Threads gleichzeitig innerhalb einer einzelnen Gruppe aktiv sein können.
Die Testarbeitslast ist Sysbench OLTP Read-Write, ein gängiges Befehlszeilentool, das Last für Online-Transaktionsverarbeitung erzeugt. Der Server läuft auf einem Intel Xeon Gold 6230 mit zwei 20-Kern-Prozessoren, Hyper-Threading ergibt 80 logische CPUs, 187 GiB DDR4-Arbeitsspeicher und eine 2,9 TB Intel NVMe SSD (Modell SSDPE2KE032T8). Das Betriebssystem ist Ubuntu 24.04 mit Kernel 6.8.0-60-generic. Die verglichenen Datenbank-Engines sind Perconas Datenbankserver 9.7.1-1 und der Open-Source-Datenbankserver 26.7.0, beide als Release-Builds. Die Testdatenbank enthält 24 GB Daten bzw. 100 Millionen Zeilen, verteilt auf 20 Tabellen in allen Läufen. Das Schema ist als herunterladbare SQL-Datei unter https://percona-lab-results.github.io/2026-interactive-metrics/schema_dump.sql verfügbar.
Parallelität ist eine weitere Dimension: Der Benchmark treibt 40, 80, 120, 160, 320, 640, 1280, 2560 und 5120 gleichzeitige Threads an. Drei Puffer-zu-Daten-Verhältnisse werden verwendet: 1:12 für eine I/O-lastige Arbeitslast, 1:2 für eine teilweise gepufferte Arbeitslast und 1:1 für eine vollständig gepufferte Arbeitslast, was InnoDB-Buffer-Pool-Größen von 2 GB, 12 GB und 32 GB entspricht. Vor jeder Messung wird eine Aufwärmphase von 600 Sekunden bzw. 10 Minuten verwendet, und der Beitrag sagt, dass die Aufwärmzeiten experimentell bestimmt wurden, bis eine weitere Erhöhung keine signifikanten Änderungen mehr ergab. Das eigentliche Messfenster beträgt 900 Sekunden bzw. 15 Minuten, basierend auf früheren Benchmark-Erfahrungen, um die Gesamttestzeit angemessen zu halten. Jede Konfiguration wird einmal ausgeführt, da die gesamte Suite bereits lange dauert.
Mehrere andere Datenbankeinstellungen werden als wichtig aufgeführt. Der InnoDB-Buffer-Pool, der Speicherbereich, in dem der Open-Source-Datenbankserver Daten- und Indexseiten zwischenspeichert, wird je nach Verhältnis auf 2 GB, 12 GB oder 32 GB gesetzt. Das Laden des Buffer-Pools beim Start und das Entladen beim Herunterfahren sind beide auf OFF gesetzt. Die Thread-Stack-Größe beträgt 512K, die Thread-Cache-Größe 256 und der Verbindungs-Backlog 4096. Die InnoDB-I/O-Kapazität ist auf 10000 gesetzt, mit einem Maximum von 20000, und die Lese-I/O-Threads sind auf 16 gesetzt. Der Beitrag weist darauf hin, dass vollständige Konfigurationsdateien für jeden Lauf von den interaktiven Diagrammen heruntergeladen werden können.
Teil 1 enthält absichtlich keine Leistungsergebnisse. Er legt die Mechanismen und das Testumfeld fest, damit die Leser genau verstehen, was gemessen wird. Der Leistungsvergleich zwischen Perconas Datenbankserver mit seinem Thread-Pool und dem neu ausgestatteten Open-Source-Datenbankserver ist Gegenstand von Teil 2. Für Teams, die Datenbanken in Produktion betreiben, bieten verwaltete Cloud- und Dateninfrastrukturen wie AEU Data verwaltete Datenbanken, automatisierte Backups, verschlüsselten Speicher, Überwachung und Hochverfügbarkeits-Bausteine, sodass ein Thread-Pool-Experiment weder Backups noch Betriebszeit gefährden muss.