A locking war story
We recently migrated JavaScript/SourceMap processing to Rust where we were hitting a lock contention problem in our processing infrastructure that kept people up for a few days. What happened, why and how did we solve it?
A locking war story | Sentry Blog Skip to main content ← Back to Blog Home We recently migrated the JavaScript and SourceMap processing from Python code over to Rust code, more specifically our Symbolicator service that is a powerhouse aimed at heavy processing. However, the first few days of pushing 100% of JavaScript events through this service kept our teams awake for far too long. Processing some of those events did not go as smoothly as it should have, and we were battling low throughput and increasing backlogs in our processing infrastructure. In the end, I tracked the root cause of that
related reading
- Rewriting Bun in Rust | Bun Blogbun.com
- Spinlocks Considered Harmfulmatklad.github.io
- A data race that doesn't compilecorentin-core.github.io
- How (and why) we rewrote our production C++ frontend infrastructure in Rustblog.nearlyfreespeech.net
- My Thoughts on the Bun Rust Rewriteandrewkelley.me
- How to do distributed locking - Martin Kleppmann's blogmartin.kleppmann.com
- How Mozilla’s Rust dramatically improved our server-side performance | Figma Blogfigma.com
- Bringing async/await to embedded Rust - Ferrous Systemsferrous-systems.com
- Async Rust Is A Bad Languagebitbashing.io
- Fixing Rust's supply chain security: The good, the bad and the uglykerkour.com
- The Problem with OpenTelemetrycra.mr
- PostgreSQL rocks, except when it blocks: Understanding locks - Citus Datacitusdata.com