Effektiv inställning av MariaDB:s trådcache: Bättre prestanda med mindre overhead

Jag ställer in MariaDB:s trådcache specifikt för att underlätta upprättandet av anslutningar och skapandet av trådar. På så sätt minskar jag Fördröjning och spara CPU‑Överbelastning, särskilt vid många korta sessioner och hög anslutningshastighet.

Centrala punkter

Följande aspekter utgör riktlinjerna för en effektiv inställning och mätning av cachen. Jag fokuserar på tydliga Värden och genomförbara Steg.

• Verkningsprincip: Återanvändning av avslutade trådar istället för kostsam nygenerering
• Relevans: Användbart vid många korta anslutningar per sekund
• Mätning: Threads_created, Connections, Threads_cached
• Gränser: Ignoreras om trådpoolen är aktiv
• Förfarande: Börja i liten skala, mäta, öka försiktigt

Så här fungerar MariaDB:s trådcache

När en anslutning bryts placerar MariaDB tråden i en cache så länge gränsen inte har nåtts. Nya anslutningar kan återanvända denna tråd, vilket sparar in den kostsamma upprättandet och Svarstid minskar. Detta märks särskilt vid många inloggningar per sekund och arbetsbelastningar med korta sessioner, där skapandet och avslutandet av trådar leder till märkbar Kostnadsfaktor . Cachen töms efter cirka fem minuters inaktivitet, vilket gör att servern inte bär på onödig belastning. Utan trådpool är standardvärdet ofta 256, vilket ger en liten buffert för typiska toppar. Jag vill dessutom påpeka att återanvändning inte löser alla problem: dålig anslutning eller felaktiga klientstrategier förblir synliga och kräver egna korrigeringar.

När det lönar sig att trimma bilen

Jag utökar cachen om applikationen skapar många korta anslutningar och räknaren Trådar_skapade växer snabbt. Ett tydligt tecken på detta är ett högt värde för Threads_created dividerat med Connections, eftersom återanvändningen då alltför ofta missar sitt syfte. I detta fall tränger nya trådar undan CPU och påverkar svarstiden negativt, medan Reuse förkortar vägen. Jag kontrollerar dock alltid om orsaken inte ligger hos klienten, till exempel på grund av onödiga återanslutningar. Om en välfungerande anslutningshantering stabiliserar belastningen behöver cachen ofta bara justeras något. Den som blint maximerar får snabbt betala med minnesförbrukning och förbiser verkliga justeringsmöjligheter i applikationslogiken.

Mätvärden som jag kontrollerar i förväg

För att ställa en korrekt diagnos använder jag ett fåtal, men uttrycksfulla nyckeltal med tydliga formler. Till att börja med läser jag Trådar_skapade, Anslutningar, Cachelagrade trådar och Trådar_anslutna och granskar trender. Det enkla förhållandet Threads_created/Connections visar hur ofta databasen bygger upp data på nytt istället för att återanvända den. Det är dessutom mycket användbart att jämföra Threads_cached med det vanliga toppvärdet för samtidiga anslutningar. Om cacheminnet och avståndet till toppvärdet förblir stora, ger jag bort Resurser eller träffa Last inte. I tabellen nedan sammanfattas viktiga nyckeltal och vad de direkt innebär:

Nyckeltal	Betydelse	tolkning	Åtgärd
Trådar_skapade	Nyttvunna trådar sedan start	Snabb tillväxt tyder på frekvent nybildning	Kontrollera cachen, minska antalet återanslutningar från klienter
Anslutningar	Totalt antal anslutningar	Underlag för kvot och trendbedömning	Övervaka utvecklingen mot belastningstoppar
Cachelagrade trådar	Trådar i cachen	Låg nivå trots hög frekvens kan vara för låg	Öka cacheminnet i små steg
Trådar_anslutna	För närvarande aktiva anslutningar	Riktlinjer för lämplig cache-storlek	Dimensionera cachen med hänsyn till typiska toppar

Stegvis anpassning i praktiken

Jag börjar med att göra mätningar under realistisk belastning och registrerar nyckeltalen före varje ändring. Därefter kontrollerar jag det aktuella värdet med VISA VARIABLER SOM 'thread_cache_size' och anteckna Bas för senare Jämförelser. Därefter ökar jag värdena i små steg och observerar om Threads_created stiger långsammare och om anslutningstiderna blir mer stabila. En enda stor förändring döljer orsakerna, därför satsar jag medvetet på små, kontrollerbara steg. Efter varje justering väntar jag på en representativ belastningsfas för att säkerställa att effekten är tillförlitlig. Först när flera belastningsfönster bekräftar bilden överväger jag nästa steg.

Rekommenderad inställningslogik och utgångsvärden

Det finns inget universellt idealvärde, därför utgår jag från typiska toppvärden och historiska data. För låga eller medelhöga anslutningshastigheter räcker det ofta med en liten till medelstor cache, särskilt nära standarden för 256. Vid kraftigt varierande belastning och många anslutningar per sekund är det en fördel med ett större intervall, så länge återanvändningen faktiskt ökar. Jag håller cachen något under de vanliga toppvärdena för Threads_connected, så att jag inte får några onödiga Resurser binder. Den som gör cachen enorm slösar bort lagringsutrymme utan att få några fördelar. Dessutom tittar jag på tillhörande bakgrundstrådar som Trådar om Page Cleaner, eftersom även de påverkar det övergripande beteendet vid hög I/O-aktivitet.

Minnesbehov per tråd och effekterna av cacheminnets storlek

Jag tar medvetet hänsyn till cacheminnets effekt. En cachelagrad tråd behåller i första hand sin trådstapel och begränsade trådmetadata. Buffertar per anslutning, såsom sortera_buffer_storlek, join_buffer_size eller nätverksbufferten frigörs vid frånkoppling och belastar inte cachen permanent. Stacken förblir däremot bunden till tråden. Som tumregel utgår jag från följande: Cacheminne ≈ thread_cache_size × thread_stack (plus en viss overhead). Vid en trådstapel Med 256–320 KB och en cache på 512 blir det redan i storleksordningen 130–170 MB bundet minne. Den som ökar stacken eller använder mycket stora cacher bör ha denna effekt i åtanke och väga den mot viktigare buffertar (t.ex. InnoDB-buffertar).

Därför kontrollerar jag alltid:

• SHOW VARIABLES LIKE 'thread_stack'; för att ta reda på hur mycket minne som är bundet per tråd
• Närheten till Cachelagrade trådar till den 95:e percentilen för Trådar_anslutna
• Om cacheförstoringen påverkar andelen Skapade trådar / Anslutningar faktiskt förbättrats

Om det inte ger någon nytta minskar jag storleken igen. Att cachen är för stor märks på att Cachelagrade trådar ligger konstant över den normala anslutningstoppen utan att fördröjningarna minskar ytterligare.

Drift på Linux och i containrar: Begränsningar och hinder

Jag kontrollerar systemomfattande gränsvärden innan jag höjer cachegränsen. Skapandet av trådar kan misslyckas på grund av operativsystemets begränsningar långt innan databasen själv når det maximala antalet anslutningar. I samband med detta kontrollerar jag följande:

• Process-/trådgränser: ulimit -u (max. processer/trådar), /proc/sys/kernel/threads-max och /proc/sys/kernel/pid_max
• Stack-gräns: ulimit -s påverkar den stack som reserveras per tråd – vilket sammantaget är relevant för stora cacheminnen
• cgroups i containern: pids.max och minnesbegränsningar; för snäva PID-gränser hämmar burst-överföringar
• Scheduler-utskrift: Om det finns väldigt många trådar utan pool kan overheaden vid kontextbyte öka; i sådana fall kan det vara bättre att använda en trådpool eller app-pooling

På multi-socket- eller NUMA-värdar övervakar jag dessutom om trådar hoppar mellan noder och därmed orsakar åtkomst till minne på avstånd. I sådana miljöer är stabila pooler ofta effektivare än att ständigt skapa nya trådar som schemaläggaren fördelar över ett stort område.

Vanliga missuppfattningar kring trådcachen

Jag undanröjer vanliga missuppfattningar för att kunna optimera på ett målinriktat sätt:

• „Mer cache = alltid snabbare.“ Det är bara om det verkligen skapas många nya trådar som cachen ger någon fördel. Annars tar jag upp minne utan att det ger någon nytta.
• „Cachen påskyndar autentiseringen.“ Cachen sparar främst in arbetet med att skapa OS-trådar. Autentisering, TLS-handskakning och eventuella DNS-uppslagningar sker för varje anslutning och behöver fortfarande optimeras separat.
• „Buffertarna per tråd förblir upptagna.“ Efter frånkopplingen frigörs dessa buffertar; i cachen kvarstår främst trådens stack.
• „En stor cache ersätter app-pooling.“ Cache på serversidan minskar kostnaderna, men poolning på app-sidan undviker dem helt. Jag överväger alltid app-poolning som det första åtgärdsalternativet.

Inverkan av TLS, DNS och autentisering

Jag gör en nyanserad bedömning av anslutningstiderna, eftersom cachen inte täcker alla delar. Höga Tider för handskakning tolkar jag ofta som ett TLS-problem (certifikatverifiering, utebliven återupptagning) eller DNS-bakåtsökning. Med skip_name_resolve=ON Jag undviker dyra omvända uppslag och förlitar mig på IP-baserade behörigheter. Även valet och konfigurationen av autentiseringspluginet påverkar inloggningsvägen. Trådcachen minskar däremot främst kostnaderna för Skapande och avslutande av trådar. Om jag fortfarande ser höga anslutningsfördröjningar trots en stor cache, fokuserar jag på TLS-parametrar, DNS och hanteringen av klientanslutningar.

Beslutslogik: Cache, trådpool eller app-pooling?

Jag fattar beslut utifrån en enkel vägledning:

• Är app-pooling tillgängligt? Om så är fallet, dimensionera korrekt. Sjunker Trådar_skapade Det är uppenbart att en liten till medelstor cache räcker som buffert.
• Är trådpoolen aktiv? Då träder tråd_cache_storlek Nej. Jag finjusterar poolen och mäter väntetiderna innan jag justerar andra inställningar.
• Många korta anslutningar utan pool? Öka cachen måttligt. Mål: en märkbar minskning av andelen Skapade trådar / Anslutningar och lugnare Connect-tider.
• Mycket hög parallellitet och hög belastning på schemaläggaren? Jag undersöker möjligheten att byta till trådpoolen, som kan erbjuda ”work-stealing” och mindre arbetarkvoter.

Det viktiga är fallback-strategin: Om en metod inte ger mätbart bättre resultat återgår jag till den senaste ändringen. På så sätt håller jag mig nära data och undviker onödig komplexitet.

Mätmetodik med exempel på frågor

Jag använder reproducerbara sökfrågor för att dokumentera framstegen. Här är en ögonblicksbild:

• SHOW GLOBAL STATUS LIKE 'Threads\_%'; Förnödenheter Trådar_skapade, Cachelagrade trådar, Trådar_anslutna
• SHOW GLOBAL STATUS LIKE 'Connections'; som underlag för kvoten
• SHOW VARIABLES LIKE 'thread\_%'; på tråd_cache_storlek och trådstapel att pröva

Jag beräknar kvoten till exempel så här:

SELECT 
  ROUND(tc.variable_value+0 / NULLIF(c.variable_value+0,0), 4) AS threads_created_per_connection
FROM information_schema.GLOBAL_STATUS tc
JOIN information_schema.GLOBAL_STATUS c
  ON tc.variable_name='Threads_created' AND c.variable_name='Connections';

För belastningstester använder jag tidsfönster. Jag tar två ögonblicksbilder (i början och slutet av ett 5–10 minuter långt intervall) och beräknar skillnaden mellan värdena. Som alternativ använder jag i en isolerad testmiljö SPOLNINGSSTATUS, för att nollställa räknare – i produktionsmiljön undviker jag detta för att inte störa andra analyser. Förutom kvoten sparar jag den 95:e och 99:e percentilen för anslutningstiden från klientövervakningen, eftersom det är just där effekterna på latensspikarna visar sig.

Identifiera: Cachen är för liten

Jag märker ofta att cachen är för liten genom att Threads_created ökar kraftigt vid konstant belastning. Samtidigt förblir Threads_cached lågt, trots att systemet hanterar många anslutningar och utnyttjandegraden är låg. Följden blir fluktuerande Fördröjningar och onödiga CPU– Belastning till följd av frekvent skapande av trådar. Om cachen ökar måttligt och nyckeltalen stabiliseras bekräftar detta diagnosen. Om belastningen avtar och kvoten förbättras avsevärt är jag på rätt väg. Om effekten uteblir söker jag specifikt efter orsaker hos klienterna, nätverksproblem eller flaskhalsar i lagringssystemet.

Identifiera: Cachen är för stor

En för stor cache märks sällan, men kan ta upp minnesutrymme som andra buffertmål saknar. Jag mäter då redan en bra kvot, men mer cache förändrar knappt något och belastar bara Resurser. Om Threads_cached konstant ligger långt över den vanliga toppnivån går nyttan förlorad. Jag minskar värdet stegvis och kontrollerar om nyckeltalen eller svarstiderna förändras. Om allt förblir stabilt satsar jag på den mindre, effektivare konfigurationen. På så sätt håller jag instansen smal och lämnar utrymme för viktigare minnesområden som InnoDB-buffert och ersättningsstrukturer för query-cache.

Särdrag: Trådpool aktiverad

Så snart trådpoolen är igång ignorerar MariaDB variabeln thread_cache_size helt. I det här läget styr en pool ett fåtal arbetare som hanterar många anslutningar och därmed förhindrar väntetider för nya trådar. Jag avgör utifrån belastningsprofilen om poolning av rätt Utgångspunkten är att cachen är större Flexibilitet levererar. Starkt parallelliserade arbetsbelastningar drar ofta nytta av poolen, medan klassiska inloggningsspikar fungerar bra med cache-återanvändning. Den som använder poolen fokuserar på dess parametrar och bortser från thread_cache_size. En bra utgångspunkt är att läsa om MariaDB:s trådpool, innan jag planerar ytterligare inställningsåtgärder.

Interaktion med applikationens anslutningspool

Jag föredrar en pool på app-sidan eftersom den håller anslutningarna öppna och avlastar databasservern. Om Threads_created förblir lågt trots hög belastning tyder det på effektiv poolning och ett lågt behov av ytterligare cache. I den här konfigurationen räcker det ofta med en liten cache som dämpar enstaka toppar och inte Resurser slösas bort. Om jag däremot ser ständiga återanslutningar bör jag först se till att app-poolingen fungerar korrekt och först därefter öka databasinställningarna. En titt på inaktivitetstider och poolstorlekar hjälper till att hitta den optimala balansen för en jämn belastning. Användbar introduktionsinformation finns i en praktisk handledning om Poolning av anslutningar, som jag använder parallellt med cacheoptimeringen.

Exempel: Konfiguration och kontroll

Jag kontrollerar först den aktuella inställningen med VISA VARIABLER SOM 'thread_cache_size' och dokumenterar belastningen. Därefter anger jag provvisoriskt ett måttligt värde som SET GLOBAL thread_cache_size = 256; eller . 512, beroende på toppar. Det är viktigt att göra en permanent ändring i konfigurationsfilen, till exempel i my.cnf under [mysqld], så att inställningarna sparas även efter en omstart. I följande belastningsfönster observerar jag Trådar_skapade och tillhörande Citat, tills jag ser en tydlig trend. Om den nya genereringen minskar markant har cachen uppnått sitt mål. Om siffrorna förblir oförändrade letar jag efter orsaker i anslutningshanteringen innan jag höjer värdet ytterligare.

Praktisk handbok: Dimensionering med riktlinjer

Jag arbetar med tillförlitliga riktvärden istället för att blint sträva efter maximering:

• Start: Aktuella toppnoteringar från Trådar_anslutna observera (över flera typiska belastningsfönster).
• Inledande dimensionering: Cache ≈ 70–90 % av den vanliga toppvärdet, med ett ytterligare tak i form av en övre gräns såsom max_connections / 2 som säkerhetsgräns.
• Stegstorlek: Öka i små steg från 64 till 128 och kvoten Skapade trådar / Anslutningar check.
• Målintervall: En tydligt sjunkande andel och ett stabilare 95:e percentil för anslutningstider; om effekten uteblir, återgå till cache.
• Uthållighet: Från och med MariaDB-versioner med SET PERSIST lagrar jag testade värden direkt på serversidan, annars i my.cnf.
• Rollback: Innan jag gör någon ändring sparar jag det tidigare värdet, så att jag snabbt kan återställa det om det skulle behövas.

I miljöer med mycket varierande dag- och nattmönster rekommenderar jag en konservativ dimensionering som jämnar ut topparna utan att binda upp onödigt mycket lagringsutrymme på natten. För särskilda belastningar (driftsättningar, Cron-vågor) planerar jag medvetet in buffertar.

Checklista för felsökning

Jag kontrollerar först om trådpoolen är aktiv och därmed inaktiverar cachen. Därefter mäter jag förhållandet mellan Threads_created och Connections under flera tidsintervall, istället för att bara ta en ögonblicksbild. Därefter jämför jag Threads_cached med toppvärdet för Threads_connected för att upptäcka över- eller underdimensionering. Om prestandan förblir svag undersöker jag applikationsåteranslutningar, nätverksfördröjningar och lagringssignaler såsom ökade I/O-väntetider. Slutligen granskar jag konkurrerande inställningar som påverkar trådar och tar fram repeterbara testscenarier. Endast på detta sätt kan jag dra tydliga slutsatser och undvika åtgärder utan en hållbar datagrund.

Förkortad version för den som har bråttom

Jag använder trådcachen för att återanvända trådar och sänka skapandekostnaderna. Detta ger effekt vid hög anslutningsfrekvens, medan en aktiv trådpool ignorerar variabeln. Framgången kan mätas genom en sjunkande andel av Trådar_skapade till Anslutningar och jämnare anslutningstider. Jag börjar i liten skala, mäter noggrant och ökar endast om siffrorna och profilen motiverar det. Poolning på klientsidan är ofta den mest effektiva åtgärden, därför börjar jag där. På så sätt uppnår jag bättre prestanda med mindre overhead och håller konfigurationen smidig.