Ga naar de inhoud 
Het Redis Slow Log laat me precies zien welke commando’s de serverthread blokkeren en hoe lang de uitvoering duurt in microseconden, zodat ik bronnen van latentie gericht kan wegwerken. Met betrouwbare drempelwaarden, een nette export en onderling gecorreleerde statistieken optimaliseer ik de Prestaties duurzaam.
Centrale punten
Voordat ik dieper op de materie inga, leg ik de belangrijkste aandachtspunten vast, zodat ik doelgericht te werk kan gaan. Ik concentreer me op duidelijke configuraties, terugkerende patronen en effectieve tegenmaatregelen. Daarnaast let ik op de relatie met de context van de klant en de systeemomgeving. Zo bereik ik een consistente Analyse zonder ruis. Vervolgens pas ik de bevindingen direct toe in aanpassingen aan de code, het gegevensmodel en de monitoring.
- Drempel en de loglengte op een verstandige manier kiezen
- Patroon via Tijd, commando’s en clients herkennen
- Langzame opdrachten door Alternatieven vervangen
- Gegevensmodel en Caching aanscherpen
- Langzaam inloggen Controle integreren
Slow Log: een korte uitleg over de werking
Ik beschouw de Slow Log als een gerichte kijk op de pure Uitvoeringstijd van een commando in de single-thread van Redis. De server schrijft automatisch een vermelding zodra de duur de via `slowlog-log-slower-than` ingestelde drempelwaarde in microseconden overschrijdt. Elk record levert mij een ID, Unix-timestamp, uitvoeringstijd, commando met argumenten, client-IP/poort en optioneel een clientnaam op. Netwerk-I/O en het verzenden van antwoorden worden bewust weggelaten uit het Slow Log, waardoor ik de daadwerkelijke blokkeringstijd van de thread zie. Juist deze scheiding helpt mij om logische oorzaken duidelijk te onderscheiden van netwerk- of clientlatentie en de Oorzaak beter te omschrijven.
Configuratie: drempelwaarde en logboeklengte
Voor een productieve start zet ik de Drempel vaak op 10.000 microseconden (ca. 10 ms); tijdens tests verlaag ik deze waarde tijdelijk om fijnere details vast te leggen. Het aantal opgeslagen vermeldingen regel ik met `slowlog-max-len`, doorgaans tussen 128 en 4096, zodat piekbelastingen goed zichtbaar blijven. Beide waarden pas ik aan in het bestand `redis.conf` of tijdens de uitvoering met `CONFIG SET`, wat me flexibele diagnosevensters biedt. Vóór grotere belastingstests verlaag ik de drempelwaarde; na afloop verhoog ik deze weer naar een realistische productiewaarde. Zo houd ik het logboek overzichtelijk, zonder belangrijke Signalen te verliezen.
| Instelling/opdracht | Dat betekent | Praktische waarde |
|---|---|---|
| slowlog-log-langzamer-dan | Drempelwaarde in microseconden voor vermeldingen | Prod: 10.000 µs; Test: 1.000–5.000 µs |
| slowlog-max-len | Maximaal aantal opgeslagen records | 128–4096 vermeldingen, afhankelijk van het volume |
| SLOWLOG GET N | Toont de laatste N records | N = 10–100 voor ad-hoccontroles |
| SLOWLOG LEN | Geeft de huidige logboeklengte terug | Regelmatig controleren |
| SLOWLOG RESET | Wis het logboek | Eerst exporteren/back-up maken |
Slow Log in het dagelijks leven uitlezen
Tijdens het dagelijkse gebruik haal ik de meest recente vermeldingen op met SLOWLOG GET en controleer ik met SLOWLOG LEN in hoeverre trage opdrachten zich opstapelen, voordat ik het logboek indien nodig met SLOWLOG RESET leegmaak. Door het logboek voorafgaand aan de reset te exporteren, voorkom ik dat ik waardevolle Geschiedenis verlies, vooral als ik trends over meerdere dagen wil vergelijken. In clusteropstellingen neem ik elke instantie en elke replica mee, omdat het slow log instantiespecifiek is en er anders blinde vlekken overblijven. Voor gestructureerde analyses koppel ik de vermeldingen aan clientgegevens zoals IP, poort en ingestelde naam, zodat ik de bron in de applicatiecode eenduidig kan identificeren. Daarnaast bekijk ik de INFO-statistieken om frequenties en latenties in de context van het totale gebruik te beoordelen.
Van gebeurtenissen naar patronen: systematische analyse
Ik bekijk eerst de opvallendste commando’s met een hoge Runtime en controleer vervolgens hoe vaak ze in totaal op de instance voorkomen. Een commando dat de drempel zelden overschrijdt, stoort minder dan een commando dat net boven de drempel ligt, maar wel duizenden keren per minuut wordt uitgevoerd. Tijdclusters tijdens cron-taken, back-ups of verkeerspieken geven mij aan of werkpieken of applicatieroutines de oorzaak zijn. Via INFO commandstats krijg ik context over het aantal aanroepen en de gemiddelde duur, wat ik gemakkelijk kan bekijken via het bericht INFO commandstats verdiep. De geïdentificeerde klantnamen uit CLIENT LIST koppel ik aan services of microservices, waardoor ik de verantwoordelijkheid toewijs en de Optimalisatie gericht plan.
Optimalisatiestrategieën: commando’s en gegevensmodel
Ik vervang dure commando’s zoals KEYS op grote hoeveelheden gegevens door SCAN met aangepaste cursors, om blokkades te voorkomen en de Latency te verkorten. Als Lua-scripts te lang duren, splits ik de logica op in meerdere kleinere stappen of maak ik gebruik van vooraf geaggregeerde gegevens. Lange uitvoeringstijden zijn vaak een symptoom van het gegevensmodel: ik splits zeer grote lijsten, sets of hashes op, gebruik extra indexen of geschiktere gegevenstypen. Bij terugkerende rekenintensieve berekeningen sla ik resultaten dichter bij de toepassing op in de cache en maak ik deze op gecontroleerde wijze ongeldig, in plaats van steeds opnieuw het opbouwen ervan te forceren. Typische verkeerde configuraties en anti-patronen vat ik praktijkgericht samen via Typische misconfiguraties samen, zodat ik vermijdbare fouten sneller kan verhelpen en de Efficiëntie verhogen.
Clientcontext en applicatiecode
In de code verminder ik het aantal roundtrips door middel van pipelining en bundeling, waardoor ik de pure Server tijd Ik verander er weliswaar niets aan, maar ik verminder de ervaren latentie per aanroep aanzienlijk. Parameters uit Slow-Log-vermeldingen laten me zien waar onnodige lussen of herhaalde toegangen ontstaan. Ik zorg ervoor dat clients via CLIENT SETNAME zinvolle namen toekennen, zodat de toewijzing binnen het team meteen duidelijk is. Ik verdeel schrijfbelastingen door hotkeys te identificeren, toegangspatronen te spreiden en TTL-strategieën te controleren. Tijdens migratiefasen of bij het gebruik van functievlaggen houd ik de vermeldingen van de betreffende paden nauwlettend in de gaten om effecten tijdig te herkennen en de kwaliteit veilig te stellen.
Bronnen, topologie en bronnen van latentie
Niet elke vertraging is het gevolg van inefficiënte commando’s; daarom controleer ik CPU-pieken, geheugenbottlenecks en netwerklatentie tegelijkertijd met de Vermeldingen in het Slow Log. Een ongunstige verdeling van de shards, te weinig replica’s of lange cross-zone-routes verlengen de waargenomen duur. Verder controleer ik RDB/AOF-instellingen en achtergrondtaken die het serverproces tijdelijk onder druk zetten. Bij hoge belasting overweeg ik schaalbaarheidsopties, mits het datamodel al is geoptimaliseerd en de juiste commando’s worden gebruikt. Pas de correlatie met systeemstatistieken geeft mij duidelijkheid. Oorzaak-gevolg‑Kettingen zichtbaar.
Slow Log integreren in Monitoring
Een speciaal dashboard toont mij de ontwikkeling van de loglengte, het aantal trage commando’s per service en gerelateerde gegevens zoals CPU- en geheugengebruik. Ik integreer de slow-log-gegevens in bestaande observability-pijplijnen en creëer zo een doorlopende Controle. In grafische gebruikersinterfaces filter ik op opdrachten, tijden en clients om afwijkingen sneller te kunnen opsporen. Voor praktische workflows maak ik gebruik van tools met slow-log-weergaven, een werkbank en exportfuncties, zoals ik die in de RedisInsight-handleiding beschrijf. Hierdoor verkort ik het diagnostische traject aanzienlijk en vergroot ik de zeggingskracht van de Metriek.
Praktische handleiding: stap voor stap
Eerst zorg ik ervoor dat slowlog-log-slower-than en slowlog-max-len op een zinvolle manier zijn ingesteld, zodat ik geen ruis veroorzaak en ook geen relevante Signalen verlies. Daarna lees ik de meest recente gegevensrecords uit, sla deze op en identificeer opvallende commando’s op basis van frequentie en duur. In de volgende stap onderzoek ik tijdvensters, koppel ik CLIENT-namen aan elkaar en zoek ik patronen in terugkerende parameters. Hieruit leid ik concrete maatregelen af voor de code, het datamodel en cachingconcepten. Tot slot neem ik de analyse op in mijn permanente monitoring, zodat ik trends vroegtijdig kan herkennen en Regressies voorkom.
Ervaringsgegevens en afstemmingscriteria
Een startwaarde van 10 ms als drempelwaarde werkt goed in veel productieomgevingen, terwijl lagere waarden bij tests nuttig zijn details leveren. Ik pas de lengte van het logbestand zo aan dat het typische dag- of weekpatronen weergeeft, zonder opslagruimte te verspillen. Ik stel een baseline vast, documenteer typische commandoverdelingen en let op sluipende veranderingen. Na een deployment kijk ik bewust even in het slow log om in een vroeg stadium te detecteren of nieuwe functies ongewenste latentiepatronen veroorzaken. Deze werkwijze levert betrouwbare inzichten op over wanneer ik bij moet sturen en hoe ik de Prestaties op lange termijn hoog houden.
Beperkingen en interpretatieaanwijzingen van de Slow Log
Ik houd er rekening mee dat het Slow Log alleen de pure uitvoeringstijd in de server-thread meet. Wachttijden in de command-queue, de kosten van de TLS-handshake of het transport van grote antwoorden via het netwerk komen daar niet in voor. Ook worden opdrachtargumenten in het Slow Log om geheugenredenen beperkt en mogelijk ingekort, waardoor ik parameters slechts als indicatie beschouw en niet als de volledige waarheid. Omdat het log op drempelwaarden werkt, krijg ik een steekproef van de traagste gevallen en geen volledige verdeling. Daarom vul ik analyses aan met latentiepercentielen uit de monitoring en gebruik ik indien nodig de geïntegreerde LATENCY-monitor (drempel via latency-monitor-threshold) om sporadische pieken te detecteren.
Bijzonderheden met betrekking tot clusters en replicatie
In clusteropstellingen controleer ik of trage commando’s geconcentreerd zijn op afzonderlijke slots of shards. Cross-slot-bewerkingen (bijv. MGET op sleutels zonder hash-tag) leiden tot fouten of omwegen en veroorzaken onnodige roundtrips die niet zichtbaar zijn in het slow log, maar die de waargenomen latentie wel verhogen. Rebalancing, failover en replicatie-inhaalprocessen beïnvloeden de systeembelasting: commando’s zoals WAIT kunnen opzettelijk langer duren totdat de bevestigingen zijn binnengekomen. Op stand-by-replica’s gelden andere toegangsprofielen; daar controleer ik de slowlog-vermeldingen afzonderlijk, omdat leesbelastingen, synchronisatie-inspanningen en achtergrondprocessen van elkaar verschillen. Voor een nauwkeurige diagnose exporteer ik het Slow Log van elke instantie en breng ik de tijdstempels over alle knooppunten heen in kaart.
Persistentie, forks en geheugengedrag
Ik houd RDB-snapshots en AOF-rewrites in de gaten: bij het forken van het Redis-proces kan Copy-on-Write leiden tot tijdelijk hoog geheugengebruik en CPU-pieken, wat op zijn beurt de uitvoeringstijd van commando’s verlengt. AOF-instellingen (bijv. appendfsync) beïnvloeden de schrijflatentie; „everysec“ is meestal een goed compromis, terwijl „always“ de duurzaamheid verhoogt, maar pieken kan bevorderen. Daarnaast let ik op actieve geheugendfragmentatie, evicties en het verwerken van verlopen sleutels. Grote afzonderlijke sleutels (bijv. hashes met tienduizenden velden) veroorzaken merkbare pauzes tijdens vervalcycli of bij het verwijderen. Met lazyfree-opties (bijv. lazyfree-lazy-eviction) ontlast ik de hoofdthread door het vrijgeven van grote structuren asynchroon te laten uitvoeren, mits het workloadprofiel hiervoor geschikt is.
Blocking-, Multi-Key- en scriptopdrachten
Ik maak onderscheid tussen commando’s met lineaire tijdcomplexiteit (O(N)) en logaritmische of constante varianten. SORT, SUNIONSTORE, ZUNIONSTORE of HGETALL op grote structuren komen vaak voor in het Slow Log. EVAL/EVALSHA zijn weliswaar atomair en praktisch, maar kunnen door interne lussen de serverthread langdurig bezighouden; kleinere, goed afgestemde deelstappen zijn hier beter. Blokkerende commando’s zoals BLPOP of XREAD BLOCK blokkeren in de eerste plaats de client, niet de serverthread – maar worden kritiek wanneer ze worden gecombineerd met zeer grote gegevensstructuren. Bij het scannen vermijd ik brede MATCH-patronen zonder indexlogica en stel ik COUNT zo in dat ik de belasting beheersbaar houd; SCAN beschermt tegen volledige blokkades, maar is geen vrijbrief voor ongerichte zoekopdrachten.
Export, automatisering en gegevensverwerking
Om reproduceerbare analyses te kunnen uitvoeren, exporteer ik het Slow Log regelmatig en standaardiseer ik het formaat. Ik vul de vermeldingen aan met klantnamen, gebruikers (ACL) en servicetags, zodat de eigenaar eenduidig vaststaat. Een eenvoudige workflow via de shell helpt me bij ad-hoc-exporten:
# JSON-achtige export van de laatste 500 vermeldingen
redis-cli SLOWLOG GET 500 > slowlog.raw
# CSV-voorbeeld (ID;tijdstempel;duur in µs;commando;client)
# Opmerking: argumenten kunnen in het slowlog worden afgekort
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
In automatiseringspijplijnen haal ik de gegevens op alle knooppunten op, normaliseer ik de tijdstempels (UTC) en stel ik statistieken samen per opdracht, per client en per tijdsvenster. Ik zorg ervoor dat ik vóór elke SLOWLOG RESET de gegevens exporteer en de rotatiefrequentie aanpas aan de loglengte, zodat er geen pieken verloren gaan.
Werkwijze voor incidentrespons
In acute gevallen zorg ik eerst voor het behoud van de status quo: ik controleer SLOWLOG LEN, exporteer ruimschoots de laatste vermeldingen en verhoog tijdelijk slowlog-max-len, zodat er geen gegevens worden weggeroteerd. Vervolgens verlaag ik de drempelwaarde gematigd, om ook patronen te kunnen zien die net onder de huidige drempel liggen. Tegelijkertijd controleer ik de CPU, het RSS-geheugen, page-fouts, netwerk-RTT en persistentiegebeurtenissen (RDB/AOF). Als bepaalde commando’s massaal voorkomen, beperk ik deze tijdelijk via feature-flags of strengere ratelimits. Bij hotkeys spreid ik de verzoeken (key-hashing/shard-spread) en verhoog ik indien nodig de replicatiecapaciteit. Zodra de piek is doorbroken, voer ik een diepgaande oorzaakanalyse uit en implementeer ik permanente oplossingen in de code en het gegevensmodel.
Kwaliteitsborging voor en na implementaties
Vóór releases verlaag ik in de staging-omgeving de drempelwaarde voor het slow-log aanzienlijk, om micro-inefficiënties in een vroeg stadium op te sporen. Ik stel aanvaardbare latentiebudgetten vast (bijv. p95/p99 per commando) en vergelijk deze met een gedocumenteerde baseline. Na de uitrol houd ik de Slow-Log-vermeldingen voor de betreffende services nauwlettend in de gaten; afwijkingen leiden tot een snelle rollback of tot gerichte optimalisaties. Eén Canary-uitrol per shard/zone helpt me om effecten geïsoleerd te observeren. Communicatie is belangrijk: elke client stelt een veelzeggende naam in, zodat ik Slow-Log-vermeldingen onmiddellijk aan een eigenaar kan toewijzen – dat versnelt de probleemoplossing enorm.
Beslissingslogica voor drempelwaarde en log-lengte
Ik stel de drempelwaarde niet alleen absoluut in, maar ook contextgevoelig: Op zeer snelle knooppunten met NVMe en voldoende CPU-capaciteit verlaag ik deze tijdens productietijden liever naar 5–8 ms om subtiele hotspots te detecteren; bij goedkopere hardware of intensief burstverkeer blijf ik conservatiever, zodat het logboek een sterk signaal behoudt. De loglengte schaal ik op basis van de commandofrequentie en het exportinterval: hoe hoger de commandofrequentie, hoe groter het venster (bijv. 2048–4096), zodat ik volledige verkeerscycli kan vastleggen. Bij belastingstests stel ik de lengte bewust hoog in en plan ik exports tijdig in, om geen pieken te missen. In rustfasen verlaag ik de waarden om geheugen te besparen en de analyse gericht te houden.
Veelvoorkomende patronen in de praktijk
Over het algemeen onderscheid ik drie categorieën oorzaken: ten eerste dure O(N)-bewerkingen op grote structuren (SORT, grote set/hash-unies, volledige iteraties), ten tweede neveneffecten van het systeem (forks, defragmentatie, evictions) en ten derde gebruikspatronen (N+1-toegangen, dubbele berekeningen, ontbrekende caching). De tegenmaatregelen vloeien hier direct uit voort: het vervangen van commando’s en het beperken van de gegevenshoeveelheid, het ontkoppelen van zware bewerkingen in taken/wachtrijen, asynchrone vrijgaven van grote objecten, strakke TTL- en ongeldigverklaringsstrategieën, en meer aggregatie dicht bij de gebruiker. Ik koppel deze maatregelen altijd aan statistieken, zodat successen meetbaar zijn en achteruitgang snel zichtbaar wordt.
Compact overzicht
Ik gebruik het Slow Log om de pure Server tijd Ik breng dure commando’s in kaart, stel passende drempels in en bescherm de gegevensrecords tegen resets. Met configuraties via redis.conf of CONFIG SET houd ik de diagnoseperiode flexibel, zonder onnodig geheugen te verbruiken. Uit de vermeldingen leid ik patronen af met betrekking tot commando’s, tijden en clients, waarna ik de commando-keuze, het gegevensmodel, caching en de applicatiecode optimaliseer. Tegelijkertijd breng ik slow-log-statistieken in verband met systeemstatistieken en APM-signalen, zodat ik oorzaken duidelijk kan toewijzen. Zo blijft de Prestaties dit is voorspelbaar en latentieproblemen verliezen hun verrassingseffect.
