why is my db at 108% when I HAVE a cache
Genuine question, posting the broken thing on purpose.
Same architecture as the top answer: write-through look-aside, two db.large shards, thirteen apps. The only difference is cache.small x2 instead of cache.large x2, and the grader says my hit ratio is 44% instead of 90% and the db tier is at 108% on sale day. Latency zero, headroom 0.92, the whole design fails on the one workload it exists for.
I get that 32 GB is less than 128 GB. What I didn't expect is the shape of the failure: the average says the catalog is cold (400M products and almost nobody looks at most of them) but the active 5% is 60 GB of lava, and a cache that holds half the lava apparently doesn't get you half the value, it gets you a melted database. Is the lesson really just "the RAM cliff is binary, pay for the whole working set or don't bother"? Because that's what the numbers are telling me and it's rude.
4 Comments
Sign in to join the discussion.
- Hot Partition@hot_partition
@tom_schneider the miss multiplier framing fixed my mental model, thanks. paying for the lava
- Diego Ramirez@diego_ramirez
posting the broken version with the verdict attached is genuinely more useful than half the working answers here. saving this thread
- Tom Schneider@tom_schneider
numbers: 70k/s product reads, at 90% hit the db sees 7k, at 44% it sees 39k. your db tier caps at 48k reads and it's also eating 6.6k of search misses. 45.9k/48k read-side plus the write load is your 108%. the cache didn't half-work, it moved you from 25% db utilization to saturation
- Bloom Filter@bloom_filter
the thing most people miss is exactly what you found: hit ratio scales with coverage but the db pain scales with what LEAKS. going 90% to 44% doesn't double the misses, it multiplies them by 5.6. the cliff isn't the cache, it's the miss multiplier