← Use cases · Data
Database and storage engines
Buffer pools and query workers scattered across nodes bleed bandwidth. Pin the pools, schedule queries where their data lives.
A database engine on a multi-socket box allocates a large buffer pool that the kernel scatters across nodes, then runs query workers on whatever core is free. The result is a steady stream of remote memory accesses and cache-line bouncing on shared counters — throughput and tail latency both suffer, and neither is obviously "a NUMA problem".
Shard the buffer pool per node with NumaSharded, run a NumaExecutor with per-node worker pools so a query executes on a worker local to its data, and replace hot shared counters with ShardedCounter to stop cache-line bouncing across the box.
How it flows
sharded Partition the buffer pool per node with NumaSharded<T>.
sched Run NumaExecutor: per-node pools, node-scoped stealing only.
sharded Swap contended global counters for ShardedCounter.
perf Confirm the locality ratio actually improved, don’t assume it.
What you get
- Queries run on workers local to their data
- Per-node buffer pools cut remote access
- Lock-free per-node counters stop cache-line bouncing
Try it on your workload
cargo add numaperf, then follow the quickstart. See the full feature set or read how it works.