← PracticeExpertMemory Model

We Sharded the Counter and It Got Slower

Pull up the evidence one item at a time, commit to a diagnosis, and only then see the schedule that actually ran.

What was reported

Our rate limiter had one atomic counter and it was a bottleneck at high thread counts, so we sharded it: eight independent counters, one per worker thread, summed on read. No lock, no atomic contention, each thread touches only its own slot. Throughput dropped by a factor of three. The results are correct every single run — it is purely a performance problem, and it gets worse the more threads we add, which is the opposite of what sharding is supposed to do.
1struct Shards {
2  uint64_t hits[8];        // 64 bytes total — one per worker
3};
4Shards shards{};
5 
6void record(int worker_id) {
7  shards.hits[worker_id]++;   // no lock, no atomic, no sharing
8}
9 
10uint64_t total() {            // called once a second
11  uint64_t s = 0;
12  for (auto h : shards.hits) s += h;
13  return s;
14}

Evidence

Nothing here is labelled as relevant. Some of it is not.

What is actually happening?