{"id":21621,"date":"2026-09-21T11:47:18","date_gmt":"2026-09-21T09:47:18","guid":{"rendered":"https:\/\/webhosting.de\/mariadb-thread-cache-richtig-einstellen-performance\/"},"modified":"2026-09-21T11:47:18","modified_gmt":"2026-09-21T09:47:18","slug":"korrekt-indstilling-af-mariadb-tradcache-for-bedre-ydeevne","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/mariadb-thread-cache-richtig-einstellen-performance\/","title":{"rendered":"Effektiv konfiguration af MariaDB-tr\u00e5dcachen: Bedre ydeevne med mindre overhead"},"content":{"rendered":"<p>Ich stelle den MariaDB Thread Cache gezielt ein, um Verbindungsaufbau und Thread-Erzeugung zu entsch\u00e4rfen. So senke ich <strong>Latenz<\/strong> und spare <strong>CPU<\/strong>\u2011Overhead, besonders bei vielen kurzen Sessions und hoher Verbindungsrate.<\/p>\n\n<h2>Zentrale Punkte<\/h2>\n\n<p>Die folgenden Aspekte bilden die Leitplanken f\u00fcr eine wirksame Einstellung und Messung des Caches. Ich konzentriere mich auf klare <strong>Werte<\/strong> und umsetzbare <strong>Schritte<\/strong>.<\/p>\n<ul>\n  <li><strong>Wirkprinzip<\/strong>: Wiederverwendung beendeter Threads statt teurer Neuerzeugung<\/li>\n  <li><strong>Relevanz<\/strong>: N\u00fctzlich bei vielen kurzen Verbindungen pro Sekunde<\/li>\n  <li><strong>Messung<\/strong>: Threads_created, Connections, Threads_cached<\/li>\n  <li><strong>Grenzen<\/strong>: Ignoriert, wenn Thread-Pool aktiv ist<\/li>\n  <li><strong>Vorgehen<\/strong>: Klein starten, messen, behutsam erh\u00f6hen<\/li>\n<\/ul>\n\n<h2>So arbeitet der MariaDB Thread Cache<\/h2>\n\n<p>Nach dem Trennen einer Verbindung legt MariaDB den Thread in einen Cache, solange das Limit nicht erreicht ist. Neue Verbindungen k\u00f6nnen diesen Thread wiederverwenden, was die teure Erstellung spart und die <strong>Antwortzeit<\/strong> senkt. Das wirkt besonders bei vielen Logins pro Sekunde und Workloads mit kurzen Sessions, in denen Erstellen und Zerst\u00f6ren von Threads zum sp\u00fcrbaren <strong>Kostenfaktor<\/strong> wird. Der Cache leert sich nach rund f\u00fcnf Minuten Inaktivit\u00e4t, wodurch der Server keine unn\u00f6tigen Altlasten anbindet. Ohne Thread\u2011Pool liegt der Standardwert h\u00e4ufig bei 256, was einen kleinen Puffer f\u00fcr typische Spitzen bietet. Ich beachte zus\u00e4tzlich, dass die Wiederverwendung nicht alle Probleme l\u00f6st: Schlechte Anbindung oder fehlerhafte Client\u2011Strategien bleiben sichtbar und erfordern eigene Korrekturen.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb-threadcache-9823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Wann sich das Tuning lohnt<\/h2>\n\n<p>Ich erh\u00f6he den Cache, wenn die Anwendung viele kurze Verbindungen erzeugt und der Z\u00e4hler <strong>Threads_created<\/strong> rasant w\u00e4chst. Ein deutliches Signal ist eine hohe Quote aus Threads_created geteilt durch Connections, denn dann verfehlt die Wiederverwendung zu oft ihr Ziel. In diesem Fall dr\u00fccken neue Threads die <strong>CPU<\/strong> und zerren an der Antwortzeit, w\u00e4hrend Reuse den Pfad verk\u00fcrzt. Ich pr\u00fcfe aber stets, ob die Ursache nicht beim Client liegt, etwa durch unn\u00f6tige Reconnects. Bringt ein sauberes Connection\u2011Handling Ruhe in die Last, braucht der Cache oft nur eine moderate Anpassung. Wer blind maximiert, zahlt schnell mit Speicherverbrauch und \u00fcbersieht echte Stellschrauben in der Applikationslogik.<\/p>\n\n<h2>Messwerte, die ich vorab pr\u00fcfe<\/h2>\n\n<p>F\u00fcr eine saubere Diagnose nutze ich wenige, aber aussagekr\u00e4ftige Kennzahlen mit klaren Formeln. Zu Beginn lese ich <strong>Threads_created<\/strong>, <strong>Connections<\/strong>, <strong>Threads_cached<\/strong> und <strong>Threads_connected<\/strong> aus und \u00fcberpr\u00fcfe Trends. Die einfache Quote Threads_created\/Connections zeigt mir, wie oft die Datenbank neu baut statt wiederzuverwenden. Sehr hilfreich ist zudem die N\u00e4he von Threads_cached zur \u00fcblichen Spitzenzahl gleichzeitiger Verbindungen. Bleiben Cache und Spitzenferne gro\u00df, verschenke ich <strong>Ressourcen<\/strong> oder treffe die <strong>Last<\/strong> nicht. Die folgende Tabelle b\u00fcndelt wichtige Kennzahlen und ihre direkte Aussage:<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Kennzahl<\/th>\n      <th>Bedeutung<\/th>\n      <th>Interpretation<\/th>\n      <th>Aktion<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Threads_created<\/td>\n      <td>Neu erzeugte Threads seit Start<\/td>\n      <td>Schnelles Wachstum deutet auf h\u00e4ufige Neuerzeugung<\/td>\n      <td>Cache pr\u00fcfen, Client\u2011Reconnects reduzieren<\/td>\n    <\/tr>\n    <tr>\n      <td>Connections<\/td>\n      <td>Gesamte Verbindungsanzahl<\/td>\n      <td>Basis f\u00fcr Quote und Trendbewertung<\/td>\n      <td>Entwicklung zur Lastspitze beobachten<\/td>\n    <\/tr>\n    <tr>\n      <td>Threads_cached<\/td>\n      <td>Threads im Cache<\/td>\n      <td>Niedrig trotz hoher Frequenz kann zu klein sein<\/td>\n      <td>Cache in kleinen Schritten erh\u00f6hen<\/td>\n    <\/tr>\n    <tr>\n      <td>Threads_connected<\/td>\n      <td>Aktuell aktive Verbindungen<\/td>\n      <td>Anhaltspunkt f\u00fcr sinnvolle Cache\u2011Gr\u00f6\u00dfe<\/td>\n      <td>Cache nahe typischer Spitzen dimensionieren<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Schrittweise Anpassung in der Praxis<\/h2>\n\n<p>Ich beginne mit Messung unter realistischer Last und erfasse die Kennzahlen vor jeder \u00c4nderung. Danach pr\u00fcfe ich den aktuellen Wert mit <code>SHOW VARIABLES LIKE 'thread_cache_size'<\/code> und notiere die <strong>Basis<\/strong> f\u00fcr sp\u00e4tere <strong>Vergleiche<\/strong>. Ich erh\u00f6he anschlie\u00dfend in kleinen Stufen und beobachte, ob Threads_created langsamer steigt und die Verbindungszeiten ruhiger werden. Eine einzelne gro\u00dfe \u00c4nderung verschleiert Ursachen, daher setze ich bewusst auf kleine, \u00fcberpr\u00fcfbare Schritte. Nach jeder Anpassung warte ich auf eine aussagekr\u00e4ftige Lastphase, damit der Effekt belastbar bleibt. Erst wenn mehrere Lastfenster das Bild best\u00e4tigen, fasse ich den n\u00e4chsten Schritt ins Auge.<\/p>\n\n<h2>Empfohlene Einstellungslogik und Ausgangswerte<\/h2>\n\n<p>Ein universeller Idealwert existiert nicht, daher richte ich mich nach typischen Spitzen und der Historie. F\u00fcr ruhige oder mittlere Verbindungsraten gen\u00fcgt oft ein kleiner bis mittlerer Cache, besonders nahe dem Standard von <strong>256<\/strong>. Bei stark schwankender Last und vielen Verbindungen pro Sekunde hilft eine h\u00f6here Spanne, solange die Wiederverwendung tats\u00e4chlich steigt. Ich halte den Cache etwas unterhalb der \u00fcblichen Spitzen von Threads_connected, damit ich keine unn\u00f6tigen <strong>Ressourcen<\/strong> binde. Wer den Cache riesig macht, verschwendet Speicher, ohne Vorteile einzusammeln. Zus\u00e4tzlich schaue ich auf begleitende Hintergrundf\u00e4den wie die <a href=\"https:\/\/webhosting.de\/mariadb-page-cleaner-threads-datenbank\/\">Page Cleaner Threads<\/a>, denn auch sie pr\u00e4gen das Gesamtverhalten bei hoher I\/O\u2011Aktivit\u00e4t.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb_thread_cache9821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Speicherbedarf pro Thread und Auswirkungen der Cache\u2011Gr\u00f6\u00dfe<\/h2>\n\n<p>Ich kalkuliere die Speicherwirkung des Caches bewusst ein. Ein gecachter Thread h\u00e4lt prim\u00e4r seinen <code>thread_stack<\/code> und geringe Thread\u2011Metadaten vor. Per\u2011Verbindungs\u2011Puffer wie <code>sort_buffer_size<\/code>, <code>join_buffer_size<\/code> oder der Netzpuffer werden beim Disconnect freigegeben und lasten den Cache nicht dauerhaft aus. Der Stack hingegen bleibt an den Thread gebunden. Als Faustwert setze ich an: <strong>Cache\u2011Speicher \u2248 thread_cache_size \u00d7 thread_stack<\/strong> (zuz\u00fcglich etwas Overhead). Bei einem <code>thread_stack<\/code> um 256\u2013320&nbsp;KB und einem Cache von 512 ergibt das schon in der Gr\u00f6\u00dfenordnung von 130\u2013170&nbsp;MB gebundenen Speicher. Wer den Stack erh\u00f6ht oder sehr gro\u00dfe Caches f\u00e4hrt, sollte diesen Effekt im Blick behalten und gegen wichtigere Puffer (z.&nbsp;B. InnoDB\u2011Buffer) abw\u00e4gen.<\/p>\n\n<p>Ich pr\u00fcfe deshalb stets:\n<\/p>\n<ul>\n  <li><code>SHOW VARIABLES LIKE 'thread_stack';<\/code> um den pro Thread gebundenen Speicher zu kennen<\/li>\n  <li>Die N\u00e4he von <code>Threads_cached<\/code> zur 95.&nbsp;Perzentil\u2011Spitze von <code>Threads_connected<\/code><\/li>\n  <li>Ob die Cache\u2011Vergr\u00f6\u00dferung die Quote <code>Threads_created \/ Connections<\/code> tats\u00e4chlich verbessert<\/li>\n<\/ul>\n<p>Bleibt der Nutzen aus, reduziere ich wieder. Ein zu gro\u00dfer Cache zeigt sich daran, dass <code>Threads_cached<\/code> dauerhaft \u00fcber der \u00fcblichen Verbindungs\u2011Spitze liegt, ohne dass Latenzen weiter sinken.<\/p>\n\n<h2>Betrieb auf Linux und in Containern: Limits und Stolpersteine<\/h2>\n\n<p>Ich verifiziere systemweite Limits, bevor ich den Cache hochsetze. Die Erstellung von Threads kann an OS\u2011Grenzen scheitern, lange bevor die Datenbank selbst an maximale Verbindungen st\u00f6\u00dft. Dabei pr\u00fcfe ich:\n<\/p>\n<ul>\n  <li><strong>Prozess\u2011\/Thread\u2011Grenzen<\/strong>: <code>ulimit -u<\/code> (max. Prozesse\/Threads), <code>\/proc\/sys\/kernel\/threads-max<\/code> und <code>\/proc\/sys\/kernel\/pid_max<\/code><\/li>\n  <li><strong>Stack\u2011Limit<\/strong>: <code>ulimit -s<\/code> beeinflusst den pro Thread reservierten Stack \u2013 in Summe relevant f\u00fcr gro\u00dfe Caches<\/li>\n  <li><strong>cgroups im Container<\/strong>: <code>pids.max<\/code> und Memory\u2011Limits; zu enge PIDs\u2011Grenzen bremsen Bursts aus<\/li>\n  <li><strong>Scheduler\u2011Druck<\/strong>: Bei sehr vielen Threads ohne Pool kann Kontextwechsel\u2011Overhead steigen; hier kann der Thread\u2011Pool oder App\u2011Pooling sinnvoller sein<\/li>\n<\/ul>\n<p>Auf Multi\u2011Socket\u2011 oder NUMA\u2011Hosts beobachte ich zus\u00e4tzlich, ob Threads \u00fcber Nodes springen und dadurch Speicherfernzugriffe verursachen. In solchen Umgebungen sind stabile Pools oft effizienter als st\u00e4ndig neue Threads, die vom Scheduler breit verteilt werden.<\/p>\n\n<h2>H\u00e4ufige Missverst\u00e4ndnisse rund um den Thread Cache<\/h2>\n\n<p>Ich r\u00e4ume g\u00e4ngige Irrt\u00fcmer aus dem Weg, um zielgerichtet zu optimieren:\n<\/p>\n<ul>\n  <li><strong>\u201eMehr Cache = immer schneller.\u201c<\/strong> Nur wenn tats\u00e4chlich viele neue Threads erzeugt werden, gewinnt der Cache. Sonst binde ich Speicher ohne Nutzen.<\/li>\n  <li><strong>\u201eDer Cache beschleunigt die Authentifizierung.\u201c<\/strong> Der Cache spart prim\u00e4r die OS\u2011Thread\u2011Erstellung. Authentifizierung, TLS\u2011Handshake und ggf. DNS\u2011Lookups finden pro Verbindung statt und bleiben unabh\u00e4ngig optimierungsbed\u00fcrftig.<\/li>\n  <li><strong>\u201ePer\u2011Thread\u2011Puffer bleiben belegt.\u201c<\/strong> Nach dem Disconnect werden diese Puffer freigegeben; im Cache verbleibt haupts\u00e4chlich der Stack des Threads.<\/li>\n  <li><strong>\u201eEin hoher Cache ersetzt App\u2011Pooling.\u201c<\/strong> Serverseitiger Cache mildert Kosten, doch App\u2011seitiges Pooling vermeidet sie. Ich ziehe App\u2011Pooling immer als ersten Hebel in Betracht.<\/li>\n<\/ul>\n\n<h2>Einfluss von TLS, DNS und Authentifizierung<\/h2>\n\n<p>Ich werte Verbindungszeiten differenziert aus, da der Cache nicht jeden Anteil adressiert. Hohe <strong>Handshake\u2011Zeiten<\/strong> deute ich h\u00e4ufig als TLS\u2011Thema (Zertifikatspr\u00fcfung, fehlende Wiederaufnahme) oder DNS\u2011R\u00fcckw\u00e4rtsaufl\u00f6sung. Mit <code>skip_name_resolve=ON<\/code> vermeide ich teure Reverse\u2011Lookups und st\u00fctze mich auf IP\u2011basierte Grants. Auch Wahl und Konfiguration des Auth\u2011Plugins beeinflussen den Login\u2011Pfad. Der Thread\u2011Cache reduziert dagegen prim\u00e4r die Kosten von <em>Thread\u2011Erstellung und -Zerst\u00f6rung<\/em>. Sehe ich trotz gro\u00dfem Cache unver\u00e4ndert hohe Connect\u2011Latenzen, fokussiere ich auf TLS\u2011Parameter, DNS und das Client\u2011Verbindungsmanagement.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb-thread-cache-boost-setup-2638.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Entscheidungslogik: Cache, Thread\u2011Pool oder App\u2011Pooling?<\/h2>\n\n<p>Ich entscheide entlang eines einfachen Pfads:\n<\/p>\n<ul>\n  <li><strong>App\u2011Pooling verf\u00fcgbar?<\/strong> Wenn ja, sauber dimensionieren. Sinkt <code>Threads_created<\/code> deutlich, reicht ein kleiner bis mittlerer Cache als Puffer.<\/li>\n  <li><strong>Thread\u2011Pool aktiv?<\/strong> Dann greift <code>thread_cache_size<\/code> nicht. Ich tune den Pool und messe Wartezeiten, bevor ich andere Stellschrauben bewege.<\/li>\n  <li><strong>Viele kurze Verbindungen ohne Pool?<\/strong> Cache moderat erh\u00f6hen. Ziel: sp\u00fcrbar fallende Quote <code>Threads_created \/ Connections<\/code> und ruhigere Connect\u2011Zeiten.<\/li>\n  <li><strong>Sehr hohe Parallelit\u00e4t und Scheduler\u2011Druck?<\/strong> Ich pr\u00fcfe den Wechsel auf den Thread\u2011Pool, der Work\u2011Stealing und engere Worker\u2011Kontingente liefern kann.<\/li>\n<\/ul>\n<p>Wichtig ist die R\u00fcckfallebene: Funktioniert ein Ansatz nicht messbar besser, nehme ich die letzte \u00c4nderung zur\u00fcck. So bleibe ich nah an den Daten und vermeide Komplexit\u00e4t ohne Gegenwert.<\/p>\n\n<h2>Messmethodik mit Beispielabfragen<\/h2>\n\n<p>Ich nutze reproduzierbare Abfragen, um Fortschritte zu belegen. F\u00fcr eine Momentaufnahme:\n<\/p>\n<ul>\n  <li><code>SHOW GLOBAL STATUS LIKE 'Threads\\_%';<\/code> liefert <code>Threads_created<\/code>, <code>Threads_cached<\/code>, <code>Threads_connected<\/code><\/li>\n  <li><code>SHOW GLOBAL STATUS LIKE 'Connections';<\/code> f\u00fcr die Basis der Quote<\/li>\n  <li><code>SHOW VARIABLES LIKE 'thread\\_%';<\/code> um <code>thread_cache_size<\/code> und <code>thread_stack<\/code> zu pr\u00fcfen<\/li>\n<\/ul>\n<p>Die Quote berechne ich z.&nbsp;B. so:\n<\/p>\n<pre><code>SELECT \n  ROUND(tc.variable_value+0 \/ NULLIF(c.variable_value+0,0), 4) AS threads_created_per_connection\nFROM information_schema.GLOBAL_STATUS tc\nJOIN information_schema.GLOBAL_STATUS c\n  ON tc.variable_name='Threads_created' AND c.variable_name='Connections';<\/code><\/pre>\n<p>F\u00fcr Lasttests setze ich auf Zeitfenster. Ich nehme zwei Snapshots (Start und Ende eines 5\u2011 bis 10\u2011min\u00fctigen Intervalls) und bilde die Differenzwerte. Optional nutze ich in einer isolierten Testumgebung <code>FLUSH STATUS<\/code>, um Z\u00e4hler zur\u00fcckzusetzen \u2013 in Produktion meide ich das, um andere Auswertungen nicht zu st\u00f6ren. Neben der Quote speichere ich 95.&nbsp;und 99.&nbsp;Perzentile der Verbindungsdauer aus dem Client\u2011Monitoring, denn genau dort zeigen sich die Effekte auf die Latenz\u2011Spitzen.<\/p>\n\n<h2>Erkennen: Der Cache ist zu klein<\/h2>\n\n<p>Ich sehe einen zu kleinen Cache oft daran, dass Threads_created bei konstanter Last stark anzieht. Gleichzeitig bleiben Threads_cached niedrig, obwohl das System viele Verbindungen verarbeitet und die Quote schlecht ausf\u00e4llt. Die Folge sind schwankende <strong>Latenzen<\/strong> und unn\u00f6tige <strong>CPU<\/strong>\u2011Last durch h\u00e4ufige Thread\u2011Erstellung. Steigt der Cache moderat und stabilisiert die Kennzahlen, best\u00e4tigt das die Diagnose. Werden die Zeiten ruhiger und die Quote deutlich besser, habe ich die richtige Richtung eingeschlagen. Bleibt der Effekt aus, suche ich gezielt nach Client\u2011Ursachen, Netzproblemen oder Engp\u00e4ssen beim Storage.<\/p>\n\n<h2>Erkennen: Der Cache ist zu gro\u00df<\/h2>\n\n<p>Ein zu gro\u00dfer Cache f\u00e4llt seltener auf, kann aber Speicher binden, der anderen Pufferzielen fehlt. Ich messe dann eine bereits gute Quote, doch mehr Cache \u00e4ndert kaum etwas und belastet nur die <strong>Ressourcen<\/strong>. Wenn Threads_cached dauerhaft weit \u00fcber der \u00fcblichen Spitze liegt, verpufft der Nutzen. Ich reduziere schrittweise und pr\u00fcfe, ob sich Kennzahlen oder Antwortzeiten ver\u00e4ndern. Bleibt alles stabil, setze ich auf das kleinere, effizientere Setup. So halte ich die Instanz schlank und lasse Raum f\u00fcr wichtigere Speicherbereiche wie InnoDB\u2011Buffer und Query\u2011Cache\u2011Ersatzstrukturen.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb-thread-cache-boost-setup-2638.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Besonderheit: Thread\u2011Pool aktiv<\/h2>\n\n<p>Sobald der Thread\u2011Pool l\u00e4uft, ignoriert MariaDB die Variable thread_cache_size vollst\u00e4ndig. In diesem Modus steuert ein Pool wenige Worker, die viele Verbindungen bedienen und so Wartezeiten f\u00fcr neue Threads verhindern. Ich entscheide anhand des Lastprofils, ob Pooling der <strong>richtige<\/strong> Ansatz ist oder der Cache mehr <strong>Flexibilit\u00e4t<\/strong> liefert. Stark parallelisierte Workloads profitieren oft vom Pool, w\u00e4hrend klassische Login\u2011Spitzen mit Cache\u2011Reuse gut fahren. Wer den Pool nutzt, fokussiert auf dessen Parameter und l\u00e4sst thread_cache_size au\u00dfen vor. Ein guter Startpunkt ist die Lekt\u00fcre zum <a href=\"https:\/\/webhosting.de\/mariadb-thread-pool-server-performance-tempel\/\">MariaDB Thread\u2011Pool<\/a>, bevor ich weitere Tuning\u2011Schritte plane.<\/p>\n\n<h2>Interaktion mit Connection Pooling der Anwendung<\/h2>\n\n<p>Ich bevorzuge einen App\u2011seitigen Pool, weil er Verbindungen offenh\u00e4lt und den Datenbankserver entlastet. Bleibt Threads_created trotz hoher Last niedrig, zeigt das wirksames Pooling und einen geringen Bedarf an zus\u00e4tzlichem Cache. In diesem Setup reicht oft ein kleiner Cache, der vereinzelte Spitzen abfedert und keine <strong>Ressourcen<\/strong> verschwendet. Sehe ich dagegen st\u00e4ndige Reconnects, wirkt zuerst sauberes App\u2011Pooling und erst dann die Vergr\u00f6\u00dferung der Datenbankeinstellung. Ein Blick auf Idle\u2011Zeiten und Pool\u2011Gr\u00f6\u00dfen hilft, den Sweetspot f\u00fcr gleichm\u00e4\u00dfige Last zu finden. N\u00fctzliche Einstiegsinfos liefert ein Praxisleitfaden zu <a href=\"https:\/\/webhosting.de\/database-connection-pooling-hosting-poolscale\/\">Connection Pooling<\/a>, den ich parallel zur Cache\u2011Optimierung heranziehe.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb_threadcache_effizient_3846.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Beispiel: Konfiguration und Kontrolle<\/h2>\n\n<p>Ich pr\u00fcfe zun\u00e4chst die aktuelle Einstellung mit <code>SHOW VARIABLES LIKE 'thread_cache_size'<\/code> und dokumentiere die Last. Danach setze ich testweise einen moderaten Wert wie <code>SET GLOBAL thread_cache_size = 256;<\/code> oder <code>512<\/code>, je nach Spitzen. Wichtig ist, dauerhaft in der Konfigurationsdatei zu \u00e4ndern, etwa in <code>my.cnf<\/code> unter <code>[mysqld]<\/code>, damit ein Neustart die Anpassung beh\u00e4lt. In den folgenden Lastfenstern beobachte ich <strong>Threads_created<\/strong> und die zugeh\u00f6rige <strong>Quote<\/strong>, bis ich einen klaren Trend erkenne. F\u00e4llt die Neuerzeugung deutlich, trifft der Cache sein Ziel. Bei unver\u00e4nderten Zahlen suche ich Ursachen im Verbindungsmanagement, bevor ich den Wert weiter erh\u00f6he.<\/p>\n\n<h2>Praxis\u2011Playbook: Sizing mit Leitplanken<\/h2>\n\n<p>Ich arbeite mit belastbaren Richtwerten, statt blind zu maximieren:\n<\/p>\n<ul>\n  <li><strong>Start<\/strong>: Aktuelle Spitzen von <code>Threads_connected<\/code> beobachten (\u00fcber mehrere typische Lastfenster).<\/li>\n  <li><strong>Erste Dimensionierung<\/strong>: <em>Cache \u2248 70\u201390&nbsp;% der \u00fcblichen Spitze<\/em>, zus\u00e4tzlich gedeckelt durch eine Obergrenze wie <em>max_connections \/ 2<\/em> als Sicherheitslimit.<\/li>\n  <li><strong>Schrittweite<\/strong>: In kleinen Stufen von 64\u2013128 erh\u00f6hen und die Quote <code>Threads_created \/ Connections<\/code> pr\u00fcfen.<\/li>\n  <li><strong>Zielkorridor<\/strong>: Deutlich sinkende Quote und ruhigere 95.&nbsp;Perzentile bei Verbindungszeiten; bleibt der Effekt aus, Cache zur\u00fccknehmen.<\/li>\n  <li><strong>Persistenz<\/strong>: Ab MariaDB\u2011Versionen mit <code>SET PERSIST<\/code> sichere ich getestete Werte direkt serverseitig, andernfalls in <code>my.cnf<\/code>.<\/li>\n  <li><strong>Rollback<\/strong>: Vor jeder \u00c4nderung lege ich den vorherigen Wert fest, um im Zweifel schnell zur\u00fcckzudrehen.<\/li>\n<\/ul>\n<p>In Umgebungen mit sehr unterschiedlichen Tag\/Nacht\u2011Profilen empfehle ich eine konservative Dimensionierung, die Peaks gl\u00e4ttet, ohne nachts unn\u00f6tig viel Speicher zu binden. F\u00fcr Sonderlasten (Deployments, Cron\u2011Wellen) plane ich bewusst Puffer ein.<\/p>\n\n<h2>Troubleshooting\u2011Checkliste<\/h2>\n\n<p>Ich kontrolliere zuerst, ob der Thread\u2011Pool aktiv ist und damit den Cache aushebelt. Anschlie\u00dfend messe ich die Quote aus Threads_created\/Connections in mehreren Zeitfenstern, statt nur einen Schnappschuss zu nehmen. Danach vergleiche ich Threads_cached mit der Spitze von Threads_connected, um \u00dcber- oder Unterdimensionierung zu erkennen. Bleibt die Leistung schwach, untersuche ich Applikations\u2011Reconnects, Netzwerk\u2011Latenzen und Storage\u2011Signale wie erh\u00f6hte I\/O\u2011Wartezeiten. Zum Schluss pr\u00fcfe ich konkurrierende Einstellungen, die Threads beeinflussen, und liefere wiederholbare Testszenarien. Nur so ziehe ich klare Schl\u00fcsse und vermeide Aktionismus ohne tragf\u00e4hige Datenbasis.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb_thread_cache_3746.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kurzfassung f\u00fcr Eilige<\/h2>\n\n<p>Ich setze den Thread\u2011Cache ein, um Threads wiederzuverwenden und die Erstellungskosten zu senken. Wirkung entfaltet das bei hoher Verbindungsfrequenz, w\u00e4hrend ein aktiver Thread\u2011Pool die Variable ignoriert. Messbar wird Erfolg \u00fcber eine sinkende Quote aus <strong>Threads_created<\/strong> zu <strong>Connections<\/strong> und ruhigere Verbindungszeiten. Ich starte klein, messe konsequent und erh\u00f6he nur, wenn Zahlen und Profil das rechtfertigen. Client\u2011seitiges Pooling bleibt oft der gr\u00f6\u00dfere Hebel, daher pr\u00fcfe ich dort zuerst. So erreiche ich mehr Performance mit weniger Overhead und halte die Konfiguration schlank.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb-optimierung-3542.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n","protected":false},"excerpt":{"rendered":"<p>Optimering af MariaDB-tr\u00e5dcachen: S\u00e5dan reducerer du overhead, m\u00e5ler \u00bbThreads_created\u00ab og forbedrer ydeevnen ved mange forbindelser.<\/p>","protected":false},"author":1,"featured_media":21614,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-21621","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datenbanken-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"109","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"MariaDB Thread Cache","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"21614","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/21621","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/comments?post=21621"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/21621\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/21614"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=21621"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=21621"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=21621"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}