Redis AOF fsync latency špičky: keď sa durabilita stane tvojím p99
Redis AOF vie spraviť z durability p99 špičky: fsync tlak a BGREWRITEAOF fork CoW. Runbook na dôkaz, bezpečné mitigácie a guardrails.
49 článkov
Redis AOF vie spraviť z durability p99 špičky: fsync tlak a BGREWRITEAOF fork CoW. Runbook na dôkaz, bezpečné mitigácie a guardrails.
Keď Prometheus štartuje desiatky minút, často je vinník WAL replay. Ako to dokázať z logov a disku, bezpečne sa zotaviť a predísť blind spotom.
Klienti timeoutujú, tcpdump ukazuje SYN (niekedy aj SYN-ACK), ale aplikácia nič neloguje. Častý vinník: Linux listen/accept fronty, ktoré sa pri load-e alebo CPU starvation preplnia.
Reloady NGINX Ingressu vedia dropovať keep-alive a robiť 502 špičky pri častých zmenách. Runbook na dôkaz reloadu, zníženie churnu a hardening.
Váš EXPLAIN vyzerá perfektne ale produkcia horí. Vinník: PostgreSQL ticho prepol z custom plánu na generic plán po dostatočnom počte vykonaní, a generic plán je katastrofálne zlý.
Prometheus native histogramy vedia odpáliť pamäť, WAL aj remote_write. Návod na postupné nasadenie, budgety a konkrétne queries na verifikáciu.
Reprodukovateľný postup na diagnostiku a odstránenie checkpoint-induced latency špičiek pomocou pgbench, pg_stat_bgwriter a WAL/IO budgetu.
Aplikácia visí, ale databáza vyzerá zdravo. Najčastejšie je vyčerpaný connection pool. Ukážem detekciu, rozumné dimenzovanie a prevenciu únikov spojení.
ReplacingMergeTree nededuplikuje pri SELECT. Merguje eventuálne. Vaše queries vracajú duplikáty kým neprebehne background merge. Tu je riešenie.
Kafka rebalance burky vedia zhoršiť lag pri scale-out. Runbook na max.poll, heartbeat, cooperative-sticky a config diffs, ktoré stabilizujú group.
Každý DNS query v K8s robí 5 neúspešných lookupov pred úspechom. ndots:5 default spôsobuje 100ms+ latenciu. Tu je ako to opraviť.
Go vidí 64 CPU hosta ale váš kontajner má limit 2 CPU. GOMAXPROCS=64 spôsobuje nadmerný context switching a throttling. Tu je riešenie.
Vaša Python appka má 4 thready ale K8s dáva 1 CPU. GIL + CFS kvóta = brutálny throttling. Ukážem prečo a ako správne nastaviť workery.
Použite PSI a cgroup v2 memory.high na vysvetlenie p99 špičiek bez OOMKill. Kubernetes runbook s príkazmi, diffs, bezpečnými mitigáciami a alertmi.
Pool size 50 lebo tak to bolo vždy? Ukážem ako použiť Little's Law na výpočet optimálnej veľkosti poolu a dokážem to load testom.
CPU vyzerá OK, ale tail latencia je katastrofálna. Ukážem ako korelovať CFS throttling s latency spikes a prečo odstránenie CPU limitov môže paradoxne pomôcť.
5 data nodov ale jeden je na 100% CPU. Nerovnomerné routing kľúče vytvárajú hot shardy. Ukážem ako detekovať skew a opraviť ho pomocou routing stratégií.
Náhodné UUID ako Primary Key spôsobujú index bloat a random I/O. Benchmark s konkrétnymi číslami - veľkosť indexu, cache hit ratio a WAL volume po 100M insertoch.
Používateľ kompromitovaný, treba revokovať JWT okamžite. Ale JWT sú immutable. Porovnávam allowlist, denylist a krátku expiráciu s performance benchmarkmi.
Pri 50k logov/sec JSON serializácia žerie 30% CPU. Štandardná knižnica encoding/json je pomalá. Benchmarkujem zap vs zerolog vs slog so skutočnými číslami.
Vacuum beží úspešne, ale disk rastie a cache hit ratio klesá. Ukážem ako kvantifikovať HOT-update eligibility pomocou pgstattuple a optimalizovať fillfactor.
Rovnaký query, rovnaké parametre, ale prod je pomalý a staging funguje. Ukážem ako reprodukovať generic plan problém s pgBouncer, Java/Go a ako ho fixnúť.
CPU je na 20% ale latencia je 500ms. Štandardné profilery neukazujú nič. Appka čaká, nepočíta. Ukážem ako použiť eBPF na nájdenie na čo čaká.
Autovacuum je buď ignorovaný alebo cargo-cult tunovaný. Ukážem ako ho premeniť na SLO-driven systém s konkrétnymi číslami, pg_stat metriky a reprodukovateľným testom.
Virtual Threads v Java 21 sľubujú jednoduchší kód ako Reactive. Benchmarkujem oba pri 10k concurrent connections a ukážem kde ktorý vyhráva.
Frontend sa vzdá po 5s ale backend pracuje ďalších 30s. Bez deadline propagácie mrháte resources na odsúdené requesty. Ukážem ako to implementovať v Go.
Heap je 50% plný ale pod dostane OOMKilled. Ukážem ako sledovať native memory (Metaspace, threads, NIO) a zabrániť container memory problémom.
Prečo má jeden pod 90% trafficu pri gRPC. Reprodukovateľný lab, riešenia od client-side LB po service mesh, a production checklist.
Váš kontajner má 2GB voľné ale beží pomaly. Page cache sa počíta proti memory limitu. File I/O vytláča code pages. Vysvetlím s benchmarkmi a riešeniami.
Jeden developer pridal user_id label. Prometheus dostal OOM. Ukážem ako detekovať high-cardinality metriky skôr než zabiajú monitoring, s relabel configami na ich drop.
SELECT * na tabuľke s JSON je 10x pomalší ako očakávané. Ukážem ako TOAST storage funguje a kedy zmeniť stratégie pre veľké stĺpce.
Praktický sizing guide pre tail sampling v OpenTelemetry Collector. Od decision_wait cez memory limity až po cost-benefit analýzu.
100 requestov zasiahne expirovanú cache súčasne. Všetkých 100 sa pýta databázy. Implementujem X-Fetch algoritmus ktorý refreshuje cache pred expiráciou bez zamykania.
Váš Redis má 4GB maxmemory ale RSS ukazuje 6GB. OOM killer zasiahne. Vysvetlím jemalloc fragmentáciu s reprodukciou a tuningom activedefrag.
Vaše pody robia 100 DNS queries per request. CoreDNS je bottleneck. Benchmarkujem NodeLocal DNS cache a ukážem konfiguráciu pre produkciu.
Full-text search bol rýchly, teraz je pomalý. Príčina: GIN index pending list narástol obrovský počas bulk insertov a každé vyhľadávanie musí teraz skenovať nezoradené pending záznamy.
Thread pool 200 lebo to hovorí Stack Overflow? Netflix algoritmus upravuje konkurenciu automaticky podľa latencie. Ukážem ako funguje s benchmarkmi.
Praktický rozbor prečo soft delete po rokoch rozbije výkon databázy. Benchmarky, partitioning riešenie a migračný checklist.
Nemôžeš pripojiť profiler k produkčnej JVM. seccomp blokuje perf_event_open, container dropol CAP_SYS_PTRACE a PodSecurityPolicy bráni privileged mode. Tu je ako profilovať aj tak.
Query skenuje celú tabuľku napriek perfektnému partial indexu. Príčina: WHERE klauzula query sa presne nezhoduje s predikátom indexu, alebo štatistiky zavádzajú plánovač.
Go aplikácia má zrazu 10,000 threadov konzumujúcich všetku pamäť. Príčina: cgo-based DNS resolution blokujúce v pomalých DNS prostrediach, obchádzajúce Go's goroutine scheduler.
CPU využitie je nízke ale requesty sú pomalé. Skrytý vinník: čas strávený čakaním v scheduler run-queue, neviditeľný pre tradičné profilery ale viditeľný s eBPF off-CPU analýzou.
Dotazy na read replikách zlyhávajú s 'canceling statement due to conflict with recovery'. Riešenie závisí od toho, ktorý z 5 typov konfliktov máte - tu je návod ako diagnostikovať a vyriešiť každý z nich.
Periodické latency špičky ktoré vyzerajú ako network jitter. Skutočná príčina: vnorené timeouty vytvárajú tisíce timerov ktoré zaťažujú Go runtime timer heap a spúšťajú GC scanning.
work_mem vyzerá malé na 256MB, ale parallel hash join so 4 workers naprieč 3 plan nodes používa 3GB. Tu je ako zabrániť PostgreSQL legitímne OOMnúť váš kontajner.
Pridanie indexu pre výkon spôsobilo 10x pomalšie zápisy. Kontra-intuitívna príčina: nový index rozbil HOT updaty, meniaci lacné in-place updates na drahé full-row rewrites s masívnym bloatom.
Apiserver je 'náhodne pomalý'. Príčina: veľké, často aktualizované ConfigMapy spúšťajú watch compaction, čo spôsobuje simultánny relist tisícov kontrolérov.
Náhodné 1-3 sekundové výpadky spojení počas deploymentov. CPU vyzerá v poriadku, pamäť stabilná. Skrytá príčina: iptables-restore drží xtables lock počas endpoint churnu.
Služba sa nemôže pripojiť k databáze - 'cannot assign requested address'. Príčina: ephemeral porty vyčerpané tisíckami socketov v TIME_WAIT stave.