Redis latentuma lēcieni: kā atrast cēloni ar SLOWLOG, LATENCY un redis-cli

Vairumam Redis latentuma lēcienu nav nekāda sakara ar to, ka Redis būtu "lēns". Redis izpilda komandas vienā galvenajā pavedienā, tāpēc viss, kas bloķē šo pavedienu uz 50 milisekundēm, liek katram klientam gaidīt 50 milisekundes. Uzdevums ir atrast, kas to bloķēja: viena smaga komanda, fork momentuzņēmumam, disks, kas aizkavēja fsync, hipervizors vai tīkls starp lietotni un serveri.

Vispirms: vai vainīgs Redis vai ceļš līdz tam?

Lietotnes taimauti mēra visu turp un atpakaļ ceļu. Pirms maināt kādu Redis iestatījumu, pārbaudiet, kur pazūd laiks:

redis-cli -h redis1 --latency            # aprites laiks no šī klienta
redis-cli -h redis1 --latency-history    # tas pats, pa laika logiem
redis-cli --intrinsic-latency 100        # palaist UZ servera, 100 sekundes
redis-cli -h redis1 INFO | grep latest_fork_usec

Redis latentuma rokasgrāmatā paskaidrots, ka --intrinsic-latency ar Redis vispār nesazinās. Tas mēra, cik ilgi kodols vai hipervizors notur procesu bez CPU, tāpēc tas jāpalaiž uz servera. Ja šis skaitlis jau ir vairākas milisekundes, neviena Redis noregulēšana jūs zem tā nenovedīs. Tā pati rokasgrāmata norāda, ka virtualizēti hosti ar trokšņainiem kaimiņiem var būt daudz sliktāki par fizisku serveri.

Ja --latency no lietotnes hosta ir augsts, bet no paša Redis hosta zems, skatieties uz tīklu, savienojumu mainību un klientu. Jauna savienojuma atvēršana katram pieprasījumam vai simtiem turp un atpakaļ ceļu MGET, konveijera vai skripta vietā pievieno latentumu, ko Redis nekad neredz.

SLOWLOG: komandas, kas bloķēja serveri

CONFIG GET slowlog-log-slower-than   # noklusējums 10000 (mikrosekundes = 10 ms)
CONFIG GET slowlog-max-len           # noklusējums 128 ieraksti
SLOWLOG LEN
SLOWLOG GET 25                       # jaunākie ieraksti: id, laiks, ilgums us, argumenti, klients
SLOWLOG RESET

Saskaņā ar SLOWLOG dokumentāciju lēnais žurnāls mēra tikai komandas izpildes laiku, nevis tīkla I/O vai atbildes sūtīšanu, un tieši šajā daļā galvenais pavediens nevar apkalpot nevienu citu. Katrā ierakstā ir ilgums mikrosekundēs, argumenti un klienta adrese, tāpēc parasti uzreiz redzams, kurš serviss to sūtīja.

Tipiski atradumi:

• KEYS produkcijas kodā vai administrēšanas skriptā. Dokumentācija to sauc par ļoti biežu latentuma avotu; aizstājiet ar SCAN.
• O(N) komandas uz lielām vērtībām: HGETALL, SMEMBERS, LRANGE 0 -1, SORT, SUNION, ZRANGE pār milzīgiem diapazoniem. Izmantojiet HSCAN/SSCAN/ZSCAN vai lapošanu.
• Milzīgas atslēgas DEL. Miljoniem elementu atbrīvošana aizņem laiku galvenajā pavedienā. UNLINK atbrīvo atmiņu fonā. Redis opcija lazyfree-lazy-user-del, kas liek DEL uzvesties kā UNLINK, pēc noklusējuma ir no; Valkey kopš 8.0 lazyfree opcijas pēc noklusējuma ir yes.
• Gari Lua skripti vai MULTI bloki, kas vienā piegājienā dara pārāk daudz.

Noklusējuma slieksnis ir 10 ms, un tiek glabāti tikai 128 ieraksti, tāpēc noslogotā serverī veci ieraksti ātri pazūd. Ja vajag vēsturi, vāciet tos regulāri. Valkey 8.1 un jaunākās versijās lēnais žurnāls ir daļa no COMMANDLOG, kas seko arī lieliem pieprasījumiem un lielām atbildēm; vecie slowlog-* parametri joprojām darbojas, bet ir novecojuši.

Latentuma monitors: lēcieni, kas nav komandas

Daži apstāšanās gadījumi SLOWLOG nekad neparādās, jo tie nav komandu izpilde. Latentuma monitors mēra iekšējus notikumus, piemēram, fork, aof-write, aof-fsync-always, expire-cycle, eviction-cycle un active-defrag-cycle. Pēc noklusējuma tas ir izslēgts (slieksnis 0), un to var ieslēgt darbības laikā:

CONFIG SET latency-monitor-threshold 100   # milisekundes, 0 = izslēgts (noklusējums)
LATENCY LATEST
LATENCY HISTORY fork
LATENCY DOCTOR

Iestatiet slieksni uz to, ko jūsu lietotne uzskata par pārāk lēnu. Katram notikumam tiek glabāta 160 paraugu laika rinda. LATENCY DOCTOR izdrukā lasāmu kopsavilkumu ar ieteikumiem. Kopš Redis 7.0 ir arī latentuma uzskaite katrai komandai ar p50, p99 un p99.9 vērtībām INFO latencystats; tā pēc noklusējuma ir ieslēgta.

Tipiskie aizdomās turamie ārpus komandām

• Fork RDB momentuzņēmumiem un AOF pārrakstīšanai. fork() darbojas galvenajā pavedienā un kopē lapu tabulu, kas aug līdz ar atmiņas apjomu. Pārbaudiet latest_fork_usec izvadē INFO un notikumu fork. Dokumentācija rāda, ka fork laiks dažādās platformās atšķiras par lieluma kārtām, un dažas vecākas Xen virtuālās mašīnas ir īpaši lēnas.
• Transparent huge pages. Ja THP ir ieslēgts, kopēšana-pie-rakstīšanas pēc fork var skart lielās lapas un radīt gan latentumu, gan papildu atmiņas patēriņu. Dokumentācija iesaka to izslēgt: echo never > /sys/kernel/mm/transparent_hugepage/enabled, pēc tam restartēt Redis.
• AOF un disks. Ar appendfsync always katrs ieraksts gaida fsync. Ar everysec fsync notiek fona pavedienā, bet, ja tas ilgst pārāk ilgi, galvenais pavediens tik un tā var bloķēties uz write(2). Cits smags I/O uz tā paša diska to pasliktina. Noturības kompromisi aprakstīti rakstā Redis noturība: RDB pret AOF.
• Mijmaiņa (swap). Ja kodols izliek Redis lapas mijmaiņā, šo atslēgu skaršana aptur procesu. Pārbaudiet Swap: rindas failā /proc/<pid>/smaps un kolonnas si/so izvadē vmstat 1.
• Daudzu atslēgu derīgums beidzas vienlaikus. Aktīvā dzēšana parasti noņem atslēgas mazos soļos, bet, ja vairāk nekā 25% no pārbaudītajām atslēgām ar TTL jau ir beigušās, cikls atkārtojas. Tāpēc viens un tas pats EXPIREAT miljoniem atslēgu var bloķēt serveri. Pievienojiet TTL nejaušu nobīdi.
• Atmiņas spiediens un defragmentācija. Izlikšanas cikli un aktīvā defragmentācija arī darbojas galvenajā pavedienā. Ja LATENCY LATEST parādās eviction-cycle vai active-defrag-cycle, skatiet Redis atmiņas fragmentācijas koeficients.

Kas mainās ar lielām datu kopām

• Fork laiks aug līdz ar atmiņu. Dokumentācijas piemērs: 24 GB instancei ar 4 kB lapām vajag aptuveni 48 MB lapu tabulu, un tā visa tiek kopēta pie katra BGSAVE vai AOF pārrakstīšanas. 100+ GB instancē šī apstāšanās klientiem var būt skaidri redzama. Plānojiet momentuzņēmumus ārpus maksimuma, apsveriet noturību tikai uz replikas un mēriet latest_fork_usec uz reālā instances izmēra.
• Kopēšanai-pie-rakstīšanas vajag brīvu RAM. Momentuzņēmuma laikā katra lapa, ko maina klienti, tiek dublēta. Lielai, rakstīšanas noslogotai instancei vajag atmiņas rezervi, citādi hosts sāk izmantot mijmaiņu, kas ir daudz sliktāk par pašu fork.
• Lielas atslēgas kļūst par lielām avārijām. Hash vai sakārtota kopa ar miljoniem elementu pārvērš "nekaitīgas" komandas vairāku sekunžu apstāšanās gadījumos un ienes tos arī replikācijā un migrācijās. Atrodiet tās ar redis-cli --bigkeys vai --memkeys, vēlams pret repliku, un sadaliet.
• Pilna atkārtota sinhronizācija sāp vairāk. Replika, kas atpaliek, izraisa jaunu RDB uz primārā ar vēl vienu fork un smagu tīkla pārraidi. Izvēlieties replikācijas rezerves bufera izmēru atbilstoši rakstīšanas apjomam, lai īsi atvienojumi neizraisītu pilnu sinhronizāciju.
• Arī diagnostikai vajag uzmanību. KEYS, DEBUG komandas vai liels SCAN count no klēpjdatora pret 100 GB primāro var izraisīt tieši to lēcienu, ko izmeklējat. Kur iespējams, analīzei izmantojiet repliku.

Praktiska pārbaužu secība

1. Mēriet no abām pusēm: --latency no lietotnes hosta un no Redis hosta, un --intrinsic-latency uz servera.
2. Izlasiet SLOWLOG GET un salīdziniet ierakstus ar taimautu laiku.
3. Ieslēdziet latentuma monitoru un pārbaudiet LATENCY LATEST un LATENCY DOCTOR.
4. Salīdziniet lēcienus ar momentuzņēmumiem, AOF pārrakstīšanu, derīguma beigu viļņiem un izlaidumiem.
5. Pārbaudiet OS: THP, mijmaiņu, diska latentumu, CPU steal virtuālajās mašīnās.