REDIS — tipy na performance ladění a konfiguraci

Petr Jůza
Jun 8, 2020 · 8 min read

Představovat REDIS mě přijde zbytečné, proto uvedu jen kvůli kontextu, že my REDIS používáme nejvíce jako cache, tedy z pohledu aplikace pro rychlý přístup k dříve uloženým datům. Není nutné se omezovat jen na tuto funkčnost, možnosti REDISu jsou mnohem větší. Co se mě osobně nejvíce na REDISu líbí, je ta celková jednoduchost, hodně vysoká výkonnost a škálovatelnost — na první pohled nezaujme výčtem funkcí, umí toho méně než konkurence, ale to co umí, tak umí perfektně.

Tento článek nebude souhrným textem, ale spíše zdroj tipů a návodů, které nám při ladění performance přijdou užitečné a sami je používáme. Většina věcí zde uvedených je poplatných všem verzím REDISu, nicméně je potřeba uvést, že my jsme konkrétně ladili verzi 3.0.7. (ano, tato verze je již několik let stará a chystáme upgrade, nicméně performance problémy bylo nutné vyřešit už teď).

Souhrnných článků na stejné téma již existuje spousta, na konci článku příkládám několik odkazů, které mě zaujali.

Pokud vás zajímá co vše REDIS umí a kde pro vás může být užitečný, pak se vám může hodit má prezentace z interního meetupu u nás ve firmě: https://www.linkedin.com/feed/update/urn:li:activity:6663879207136952320

Doporučení pro sběr provozních dat

Pro sběr dat z chování REDISu je vhodné mít přípravenou sadu příkazů nebo přímo skript, který se rychle spustí a posbírá vše důležité. Úplně nejlepší samozřejmě je, pokud je možné mít na produkci trvalý sběr dat v pravidelných intervalech. Performance overhead s tím spojený je zcela minimální, obavy jsou často zbytečné. Nejvíce se nám osvědčila tato sada:

  • sledování vývoje počtu klíčů, paměti, requestů a připojení, vše navíc v interaktivním módu (defaultně se spouští každou sekundu). Užitečné pro zjištění celkového stavu REDISu.

redis-cli --stat

  • zjištění nejpomalejších příkazů. Užitečné pro nalezení konkrétních volání, kde je největší problém (pozn. výpis je ovlivněn konf. parametrem slowlog-log-slower-than, který v defaultním nastavení loguje všechny commandy trvající déle než 10ms.). Výpis obsahuje záznamy od startu REDISu nebo od resetování — SLOWLOG RESET.

SLOWLOG GET 20

  • sledování latence. REDIS obsahuje interní monitoring latencí, který je skvělým nástrojem pro výkonnostní ladění. Samotný monitoring má minimální overhead, přitom je dle konfigurace defaultně vypnutý (latency-monitor-threshold 0) — doporučujeme jeho aktivaci (CONFIG SET latency-monitor-threshold 50). Výpis obsahuje záznamy od startu REDISu nebo od resetování — LATENCY RESET.

LATENCY DOCTOR

  • výpis přehledu připojení do REDISu. Užitečné pro detailní analýzu jednotlivých připojení. (pozn. níže uvedený příkaz nemá interaktivní mód, je tedy nutné si pomoci vlastním skriptem pro sběr dat v pravidelných a krátkých časových intervalech, ideálně v řádu malých jednotek sekund)

CLIENT LIST

  • zjištění struktury a velikosti uložených dat. Užitečné pro analýzu dat. (Upozornění: spuštění tohoto příkazu má mírný výkonnostní overhead, tedy nepouštět v největších výkonnostních zátěžích)

redis-cli --bigkeys

  • sledování paměti (od 4.x verze). Užitečné pro analýzu využití paměti, zda není někde nějaké úzké hrdlo v průběhu používání REDISu.

MEMORY DOCTOR

Pozn.: sledování latence je možné i přes redis-cli pomocí parametrů — latency nebo — latency-history. Toto sledování se provádí přes opakované volání PING requestů ve vysoké frekvenci, viz https://redis.io/topics/rediscli#monitoring-the-latency-of-redis-instances. Výhodou je interaktivní mód, který umožňuje sledování průběhu měření, nicméně pro samotnou analýzu reálného provozu je lepší používat interní monitorovací framework, který měří reálný provoz REDISu včetně reálných commandů.

Sentinel vs cluster

Používáme celkem častý model a to 1x master, 2x slave a to vše v jednom Sentinelu:

  • slave jsou pouze pro čtení a tedy slouží pouze jako backup řešení v případě failoveru

Aplikační doporučení

  • nepoužívat pouze základní datový typ klíč-řetězec, ale i ostatní datové typy, které jsou často rychlejší

Konfigurace REDISu a Sentinelu

  • velikost aktuálního output bufferu je ovlivněna zátěží (tj. počty zpracovávaných požadavků) a samozřejmě výstupem generovaným vstupními commandy. Velikost output bufferu lze omezovat, aby REDIS nemusel čekat, když klient nebude dostatečně rychle výstupní data odebírat. Více https://redis.io/topics/clients#output-buffers-limits

Zátěžové testování

Zátěžové testy jsme nejdříve začali provádět pomocí nástroje redis-benchmark (https://redis.io/topics/benchmarks), ale nebyli jsme úplně spokojeni s možností nastavení samotných testů a nepodařilo se nám vytvořit dostatečně velkou zátěž na samotný REDIS. Mnohem více jsme byli spokojeni s nástrojem memtier_benchmark (https://github.com/RedisLabs/memtier_benchmark).

Pozn. bohužel dokumentace je k nástroji poskromnu a co se nám nepodařilo rozchodit je iniciální nalití dat pomocí funkce import. Existuje k tomu sice nějaký popis, sem tam nějaká informace na internetu (např. zde), ale pořád málo, aby nám to stačilo. Nakonec jsme úvodní load dat udělali přes “mass import” pomocí REDIS protokolu. Je to opravdu hodně rychlé, jen na MacOS je potřeba si dát pozor na konce řádků, protože v protokolu je vyžadováno \r\n.

Info z testování:

  • použitá topologie: 1x master, 2x slaves, Sentinel

Použitá parametrizace zátěžových testů:

memtier_benchmark -s redis1 -t 4 -c 500 --ratio=1:4 -n 2000 --reconnect-interval=70 --key-minimum=1 --key-maximum=100000 --key-pattern=G:G --data-size-range=100-6000 --data-size-pattern=S --hide-histogram

memtier_benchmark -s redis1 -t 4 -c 500 --ratio=1:4 -n 2000 --reconnect-interval=5 --key-minimum=1 --key-maximum=100000 --key-pattern=G:G --data-size-range=100-6000 --data-size-pattern=S --hide-histogram

Při změně, kdy pro každý request se bude vytvářet nové připojení, tak:

  • CPU klesne tak na 40–50%

memtier_benchmark -s redis1 -t 4 -c 500 --ratio=1:4 -n 2000 --reconnect-interval=1 --key-minimum=1 --key-maximum=100000 --key-pattern=G:G --data-size-range=100-6000 --data-size-pattern=S --hide-histogram

Pokud chcete vidět všechny nastavené parametry pro memtier, pak použijte--show-config.

V průběhu psaní tohoto článku se postupně připravujeme na upgrade na poslední 5.x verzi. Zatím provádíme takové “smoke” performance testy, kdy ty samé testy co jsme dělali pro 3.x verzi provádíme na stejném prostředí a ve stejných podmínkách i s verzí 5.x a tak nějak si tu novou verzi oťukáváme. A musím přiznat, že jsem čekal viditelné rozdíly v rychlosti resp. latency a nic takového se nekonalo. Těch vylepšení týkajících se performance a optimalizace práce s pamětí nebo I/O mezi verzemi 3.x a 5.x bylo hodně, ale zatím to nikde nevidím. Budeme zkoušet dál, přidávat složitější scénáře a hlavně pak i se samotnou aplikací zkoušet, tak jsem zvědavý …

OpenWise Tech blog

Stories from our development

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store