Why Databases Cry At Night
summary
Databases fail for concrete, measurable reasons: a client runs 200 concurrent backups to slow network storage and gets timeouts until backups are serialized; transaction durability relies on write‑through/fsync so bypassing OS cache drops throughput from gigabytes/sec to megabytes/sec; an experiment with lmdb shows 100 sequential versus random key commits produce far fewer physical seeks and lower latency; use Process Monitor and CrystalDiskMark (and the mentioned up to this benchmark) to measure IOPS, write‑through speed and reveal LSM compaction and index choices that cause real slowdowns.
AI-written summary · about
chapters (4)
related talks
42mWhy databases cry at night?
35mDatabase Stalls, From the Ordinary to the Obscure
29mMySQL Performance for DevOps
34mThe Computer Wants to Lose Your Data
35mQuestioning Database Claims: Design Patterns of Storage Engine
58mTroubleshooting CPU Performance Issue for SQL Developers
41mUsing Databases to Pull Your Application Weight
57mDSS Keynote — Back to the Future: Prepare Your Data Infrastructure for Anything