Hoppa till innehåll 
Redis Slow Log visar mig exakt vilka kommandon som blockerar servertråden och hur lång tid det tar att köra dem i mikrosekunder, så att jag kan åtgärda källorna till latensen på ett målinriktat sätt. Med tillförlitliga tröskelvärden, en ren export och korrelerande mätvärden optimerar jag Prestanda hållbar.
Centrala punkter
Innan jag går in på djupet fastställer jag de viktigaste fokusområdena så att jag kan gå tillväga på ett målinriktat sätt. Jag koncentrerar mig på tydliga konfigurationer, återkommande mönster och effektiva motåtgärder. Dessutom beaktar jag kopplingen till kundens sammanhang och systemmiljön. På så sätt uppnår jag en konsekvent Analys utan brus. Därefter omsätter jag insikterna direkt i anpassningar av kod, datamodell och övervakning.
- Tröskelvärde och välja en lämplig logg-längd
- Mönster över Tid, identifiera kommandon och klienter
- Gå igenom långsamma kommandon Alternativa lösningar ersätta
- Datamodell och Caching strama åt
- Långsamma inloggningar Övervakning integrera
Slow Log: En kort förklaring av hur det fungerar
Jag ser Slow Log som en fokuserad syn på den rena Exekveringstid av ett kommando i Redis single-thread. Servern skriver automatiskt en post så snart varaktigheten överskrider det tröskelvärde i mikrosekunder som ställts in via slowlog-log-slower-than. Varje datapost ger mig ID, Unix-tidsstämpel, exekveringstid, kommando med argument, klient-IP/port och valfritt ett klientnamn. Nätverks-I/O och svaröverföring utelämnas medvetet från Slow Log, vilket gör att jag kan se trådens faktiska blockeringstid. Just denna uppdelning hjälper mig att tydligt skilja mellan logiska orsaker och nätverks- eller klientlatens samt att Orsak att avgränsa bättre.
Konfiguration: Tröskelvärde och logglängd
För en produktiv start sätter jag Tröskelvärde Ofta till 10 000 mikrosekunder (ca 10 ms), men i tester sänker jag den tillfälligt för att fånga upp finare detaljer. Antalet lagrade poster styr jag med slowlog-max-len, vanligtvis mellan 128 och 4096, så att belastningstoppar förblir tydligt synliga. Båda värdena ändrar jag antingen i redis.conf eller under körning med CONFIG SET, vilket ger mig flexibla diagnostikfönster. Innan större belastningstester sänker jag tröskelvärdet, och när testerna är avslutade höjer jag det igen till ett realistiskt produktionsvärde. På så sätt håller jag loggen smal utan att viktiga Signaler ...att förlora.
| Inställning/kommando | Betydelse | Praktiskt värde |
|---|---|---|
| långsammare-än-log-log | Tröskelvärde i mikrosekunder för poster | Produktion: 10 000 µs; Test: 1 000–5 000 µs |
| slowlog-max-len | Maximalt antal sparade poster | 128–4 096 poster beroende på volym |
| SLOWLOG GET N | Visar de senaste N posterna | N = 10–100 för ad hoc-kontroller |
| SLOWLOG LEN | Returnerar den aktuella logglängden | Kontrollera regelbundet |
| SLOWLOG RESET | Rensa loggen | Exportera/spara först |
Läsa av Slow Log i vardagen
I den dagliga driften hämtar jag de senaste posterna med SLOWLOG GET och kontrollerar med SLOWLOG LEN hur mycket långsamma kommandon som samlas, innan jag vid behov tömmer loggen med SLOWLOG RESET. En export före återställningen förhindrar att jag förlorar värdefull Historia förlorar, särskilt när jag vill jämföra trender över flera dagar. I klusterkonfigurationer inkluderar jag varje instans och varje replik, eftersom Slow Log är instansspecifikt och det annars uppstår blinda fläckar. För strukturerade analyser kopplar jag ihop posterna med klientinformation som IP, port och angivet namn, så att jag entydigt kan identifiera källan i applikationskoden. Dessutom tittar jag på INFO-statistiken för att utvärdera frekvenser och latenser i sammanhanget av den totala användningen.
Från händelser till mönster: Systematisk analys
Jag tittar först på de kommandon som oftast sticker ut och som har hög Runtid och kontrollerar sedan hur ofta de totalt sett förekommer på instansen. Ett kommando som sällan överskrider tröskelvärdet stör mindre än ett som ligger minimalt över tröskelvärdet men som körs tusentals gånger per minut. Tidsmässiga kluster under cron-jobb, säkerhetskopieringar eller trafiktoppar avslöjar för mig om orsaken är arbetsbelastningstoppar eller applikationsrutiner. Via INFO commandstats får jag kontext om antalet anrop och genomsnittliga varaktigheter, vilket jag enkelt kan se i inlägget INFO commandstats fördjupa mig i. Jag kopplar ihop de klientnamn som jag har identifierat från CLIENT LIST med tjänster eller mikrotjänster, vilket gör att jag kan tilldela ansvaret och Optimering planerar målmedvetet.
Optimeringsstrategier: Kommandon och datamodell
Jag ersätter dyra kommandon som KEYS på stora datamängder med SCAN med anpassade markörer för att undvika blockeringar och för att Fördröjning att minska. När Lua-skript körs för länge delar jag upp logiken i flera mindre steg eller använder föraggregerade data. Ofta är långa körtider ett tecken på problem med datamodellen: Jag delar upp mycket stora listor, set eller hash-tabeller, använder ytterligare index eller mer lämpliga datatyper. Vid återkommande resurskrävande beräkningar cachelagrar jag resultaten närmare applikationen och ogiltigförklarar dem på ett kontrollerat sätt, istället för att tvinga fram en omberäkning gång på gång. Typiska felkonfigurationer och antimönster sammanfattar jag på ett praktiskt sätt via Typiska felkonfigurationer tillsammans, så att jag snabbare kan rätta till misstag som går att undvika och Effektivitet öka.
Klientkontext och applikationskod
I koden minskar jag antalet rundresor genom pipelining och gruppering, vilket gör att den rena Servertid Det förändrar visserligen inte något, men minskar den upplevda latensen per anrop avsevärt. Parametrar från Slow Log-poster visar mig var onödiga loopar eller upprepade åtkomstförsök uppstår. Jag ser till att klienter tilldelas meningsfulla namn via CLIENT SETNAME, så att tilldelningen omedelbart blir tydlig för teamet. Jag fördelar skrivbelastningar genom att identifiera hotkeys, sprida åtkomstmönster och granska TTL-strategier. Vid migreringsfaser eller funktionsflaggor övervakar jag specifikt posterna för berörda sökvägar för att snabbt kunna upptäcka effekter och kvalitet för att säkra.
Resurser, topologi och källor till latens
Det är inte alltid som långsamhet beror på ineffektiva kommandon, därför kontrollerar jag CPU-toppar, minnesflaskhalsar och nätverksfördröjningar parallellt med poster i Slow Log. En ogynnsam shardfördelning, för få repliker eller långa vägar mellan zoner ökar den upplevda varaktigheten. Jag kontrollerar dessutom RDB/AOF-inställningar och bakgrundsjobb som tillfälligt belastar serverprocessen. Vid hög belastning överväger jag skalningsalternativ om datamodellen redan är optimerad och kommandovalet är korrekt. Först korrelationen med systemmetriker ger mig en tydlig bild Orsak–verkan‑kedjor synliga.
Integrera Slow Log i övervakningen
En särskild översiktssida visar utvecklingen av loggarnas längd, antalet långsamma kommandon per tjänst och relaterade faktorer som CPU- och minnesanvändning. Jag integrerar slow-log-data i befintliga observabilitetspipelines och skapar därmed en kontinuerlig Övervakning. I grafiska gränssnitt filtrerar jag efter kommandon, tider och klienter för att snabbare kunna identifiera avvikelser. För praktiska arbetsflöden använder jag verktyg med Slow-Log-vyer, Workbench och exportfunktioner, sådana som jag har i RedisInsight-handbok beskriver. På så sätt förkortar jag diagnosprocessen avsevärt och ökar betydelsen av Mätetal.
Praktisk handbok: Steg för steg
Först ser jag till att inställningarna för slowlog-log-slower-than och slowlog-max-len är lämpliga, så att jag varken skapar brus eller missar relevant Signaler förlorar. Därefter läser jag ut de senaste dataposterna, sparar dem och identifierar kommandon som sticker ut med avseende på frekvens och varaktighet. I nästa steg undersöker jag tidsfönster, kopplar samman CLIENT-namn och letar efter mönster i återkommande parametrar. Utifrån detta utarbetar jag konkreta åtgärder i koden, i datamodellen samt i caching-koncepten. Slutligen överför jag utvärderingen till min permanenta övervakning, så att jag kan upptäcka trender i ett tidigt skede och Regressioner förhindra.
Erfarenhetsvärden och inställningskriterier
Ett startvärde på 10 ms som tröskelvärde fungerar bra i många produktionsmiljöer, medan lägre värden kan vara till hjälp vid tester Detaljer leverera. Jag anpassar loggens längd så att den återspeglar typiska dags- eller veckomönster utan att slösa bort lagringsutrymme. Jag fastställer en baslinje, dokumenterar typiska kommandofördelningar och håller utkik efter smygande förändringar. Efter en driftsättning tittar jag medvetet i Slow Log för att tidigt upptäcka om nya funktioner skapar oönskade fördröjningsvägar. Denna disciplin ger tillförlitliga indikationer på när jag bör göra justeringar och hur jag ska Effekt upprätthålla på lång sikt.
Begränsningar och tolkningsanvisningar för Slow Log
Jag tar hänsyn till att Slow Log endast mäter den rena exekveringstiden i servertråden. Väntetider i kommandokön, kostnader för TLS-handskakning eller överföring av stora svar över nätverket syns inte där. Av minnesmässiga skäl begränsas och eventuellt förkortas även kommandoargument i Slow Log, varför jag betraktar parametrarna endast som en indikation och inte som den fullständiga sanningen. Eftersom loggen fungerar tröskelvärdesbaserat får jag ett urval av de långsammaste fallen och inte en fullständig fördelning. Därför kompletterar jag utvärderingarna med latenspercentiler från övervakningen och använder vid behov den integrerade LATENCY-monitorn (tröskelvärde via latency-monitor-threshold) för att upptäcka sporadiska toppar.
Särdrag hos kluster och replikering
I klusterkonfigurationer kontrollerar jag om långsamma kommandon är koncentrerade till enskilda slots eller shards. Operationer som sträcker sig över flera slots (t.ex. MGET på nycklar utan hash-tagg) leder till fel eller omvägar och genererar onödiga rundresor som inte syns i Slow Log, men som ökar den upplevda latensen. Ombalanseringar, failover och replikeringsuppföljningar påverkar systembelastningen: kommandon som WAIT kan avsiktligt ta längre tid tills bekräftelser har kommit in. På standby-repliker gäller andra åtkomstprofiler; där granskar jag slowlog-poster separat, eftersom läsbelastningar, synkroniseringskostnader och bakgrundsprocesser skiljer sig åt. För en tydlig diagnos exporterar jag slow log från varje instans och korrelerar tidsstämplarna över alla noder.
Persistens, förgreningar och lagringsbeteende
Jag håller ett öga på RDB-snapshots och AOF-omskrivningar: När Redis-processen förgrenas kan Copy-on-Write leda till tillfälligt höga minneskrav och CPU-toppar, vilket i sin tur förlänger kommandots körningstid. AOF-inställningar (t.ex. appendfsync) påverkar skrivfördröjningarna; „everysec“ är oftast en bra kompromiss, medan „always“ ökar hållbarheten men kan bidra till toppar. Dessutom beaktar jag aktiv minnesdefragmentering, evictions och hanteringen av utgångna nycklar. Stora enskilda nycklar (t.ex. hash-tabeller med tiotusentals fält) orsakar märkbara avbrott i utgångscykler eller vid raderingar. Med lazyfree-alternativ (t.ex. lazyfree-lazy-eviction) avlastar jag huvudtråden genom att låta frigörandet av stora strukturer ske asynkront, förutsatt att arbetsbelastningsprofilen lämpar sig för detta.
Blockering-, Multi-Key- och skriptkommandon
Jag skiljer mellan kommandon med linjär tidskomplexitet (O(N)) och logaritmiska eller konstanta varianter. SORT, SUNIONSTORE, ZUNIONSTORE eller HGETALL på stora strukturer dyker ofta upp i Slow Log. EVAL/EVALSHA är visserligen atomära och praktiska, men kan genom interna slingor binda servertråden under lång tid; mindre, väl avstämda delsteg är bättre här. Blockerande kommandon som BLPOP eller XREAD BLOCK blockerar främst klienten, inte servertråden – men blir kritiska när de kombineras med mycket stora datastrukturer. Vid skanning undviker jag breda MATCH-mönster utan indexlogik och kalibrerar COUNT så att jag kan hålla belastningen under kontroll; SCAN skyddar mot fullständiga blockeringar, men är ingen fribiljett för oriktade sökningar.
Export, automatisering och databehandling
För att säkerställa reproducerbara analyser exporterar jag regelbundet Slow Log och standardiserar formatet. Jag kompletterar posterna med klientnamn, användare (ACL) och servicetaggar så att ägarskapet framgår tydligt. En enkel arbetsflödesprocess via Shell underlättar för mig vid ad hoc-exporter:
# JSON-liknande export av de senaste 500 posterna
redis-cli SLOWLOG GET 500 > slowlog.raw
# CSV-exempel (ID;tidsstämpel;varaktighet µs;kommando;klient)
# Obs! Argument kan vara förkortade i Slow Log
redis-cli --raw SLOWLOG GET 200 | awk '
BEGIN{FS="\n"; OFS=";"}
/1\)/{id=$2} /2\)/{ts=$2} /3\)/{dur=$2} /4\)/{cmd=$0; gsub(/^[^"]*"/,"",cmd); gsub(/"[^$]*/,"",cmd)} /5\)/{client=$0}
/5\)/{print id,ts,dur,cmd,client}
' > slowlog.csv
I automatiseringspipelines hämtar jag data från alla noder, normaliserar tidsstämplar (UTC) och skapar mätvärden per kommando, per klient och per tidsfönster. Jag ser till att exportera före varje SLOWLOG RESET och anpassa rotationsfrekvensen efter loggens längd, så att inga toppar går förlorade.
Arbetsmetoder för incidenthantering
I akuta fall säkerställer jag först status quo: Jag kontrollerar SLOWLOG LEN, exporterar de senaste posterna i stor utsträckning och höjer slowlog-max-len tillfälligt så att inga data roterar bort. Därefter sänker jag tröskelvärdet något för att även kunna se mönster som ligger strax under det tidigare tröskelvärdet. Parallellt med detta övervakar jag CPU, RSS-minne, page-faults, nätverks-RTT samt persistenshändelser (RDB/AOF). Om enskilda kommandon förekommer i stora mängder reducerar jag dem tillfälligt genom feature-flags eller snävare hastighetsbegränsningar. När det gäller snabbtangenter sprider jag åtkomstförfrågningarna (Key-Hashing/Shard-Spread) och ökar vid behov replikeringskapaciteten. Så snart toppen har passerats genomför jag en djupare orsaksanalys och implementerar permanenta korrigeringar i koden och datamodellen.
Kvalitetssäkring före och efter driftsättningar
Innan en release sänker jag tröskelvärdet för Slow Log avsevärt i staging-miljön för att tidigt upptäcka mikroineffektiva delar. Jag fastställer acceptabla latensbudgetar (t.ex. p95/p99 per kommando) och jämför dem med en dokumenterad baslinje. Efter utrullningen övervakar jag noggrant Slow Log-posterna för de berörda tjänsterna; avvikelser leder till en snabb återställning eller till riktade optimeringar. En Canary-utrullning per shard/zon hjälper mig att observera effekterna isolerat. Kommunikationen är viktig: Varje klient anger ett beskrivande namn så att jag omedelbart kan koppla Slow Log-poster till en ansvarig – det påskyndar problemlösningen avsevärt.
Beslutslogik för tröskelvärde och loglängd
Jag väljer tröskelvärdet inte bara i absoluta termer, utan också utifrån sammanhanget: På mycket snabba noder med NVMe och riklig CPU-kapacitet sänker jag den under produktionstiderna hellre till 5–8 ms för att upptäcka små hotspots; vid kostnadseffektiv hårdvara eller kraftig burst-trafik är jag mer försiktig, så att loggen förblir signalstark. Jag skalar loggens längd efter kommandofrekvensen och exportintervallet: ju högre kommandofrekvens, desto större fönster (t.ex. 2048–4096), så att jag fångar upp hela trafikcykler. Vid belastningstester ställer jag medvetet in en hög längd och planerar in exporter i realtid för att inte missa några toppar. Under lugna perioder sänker jag värdena för att spara minne och hålla analysen fokuserad.
Vanliga mönster i praktiken
I allmänhet ser jag tre typer av orsaker: För det första kostsamma O(N)-operationer på stora strukturer (SORT, stora set-/hash-unioner, fullständiga iterationer), för det andra biverkningar av systemet (forkar, defragmentering, utkastningar) och för det tredje användningsmönster (N+1-åtkomster, dubbla beräkningar, bristande cachelagring). Åtgärderna följer direkt av detta: ersättning av kommandon och begränsning av datamängden, avkoppling av tunga operationer till jobb/köer, asynkron frigivning av stora objekt, tydliga TTL- och ogiltigförklaringsstrategier samt mer aggregering nära användaren. Jag kopplar alltid dessa åtgärder till mätvärden, så att framgångar kan mätas och försämringar snabbt upptäcks.
Kompakt sammanfattning
Jag använder Slow Log för att mäta den rena Servertid för att synliggöra kostsamma kommandon, ställer jag in lämpliga tröskelvärden och skyddar dataposterna mot återställningar. Med konfigurationer via redis.conf eller CONFIG SET håller jag diagnostikperioden flexibel utan att ta upp onödigt minne. Utifrån posterna identifierar jag mönster i kommandon, tider och klienter och optimerar därefter valet av kommandon, datamodellen, cachningen och applikationskoden. Parallellt korrelerar jag statistik från slow-loggen med systemmetriker och APM-signaler för att tydligt kunna identifiera orsakerna. På så sätt förblir Prestanda Det går att planera, och latensproblem förlorar sin överraskningseffekt.
