Detecting and Fixing Unbound Concurrency Problems
summary
Service crashes stem from millions of goroutines spawned by a work queuing routine that is created per request and blocks waiting on a five-worker channel, visible via pprof heap and goroutine profiles showing 10,000 goroutines stuck in Go park. Reproduction uses a benchmark that simulates a slow log sink, and the fix replaces multiple channels with a single buffered work channel with timeout and configurable size, dropping logs on timeout to bound memory and keep predictable usage.
AI-written summary · about
chapters (7)
- 0:00Start
- 2:38Looking at the code
- 12:49More memory
- 17:02Fix the slow ingestion
- 19:07Fix the code
- 20:28Understanding the code
- 31:59Solution explained
related talks
47mDeadlocks: The Dark Side of Concurrency
24mMastering Concurrency in Go: From Patterns to Production
58mUnbound Concurrency in Go
47mUnbounded Concurrency in Go
31mConcurrent Server Architectures
27mProduction Ready Concurrency
01h 01mRoundtable: Concurrency
26mConcurrency primitives of Golang - how to use and how not to