ClickhouseAnnouncement
Announcing Silk: a silky smooth fiber runtime for ClickHouse
Summary
Silk is a C++ stackful-fiber library and scheduler created for ClickHouse’s highly concurrent, I/O-bound components, including object-storage I/O, distributed cache lookups, replica coordination, and HTTP fan-out. Its design combines one pinned OS scheduler thread per CPU, NUMA-aware work stealing, io_uring for asynchronous I/O and timers, and zero heap allocation in the steady-state hot path; fiber stacks are mmap’d from per-fiber pools with guard pages, while runtime containers are intrusive. The post reports benchmarks including roughly 3.6-nanosecond fiber yields with cross-CPU stealing, 5.9 million file IOPS in a working configuration, and about fifteen times boost::asio’s throughput at one connection. At 10,000 concurrent S3-style requests, internal measurements showed a roughly 65% improvement in 99.9th-percentile latency versus an equivalent thread-pool executor, with identical median throughput; distributed cache is the first intended ClickHouse integration.
Context
ClickHouse’s existing thread-based concurrency model suits long-running query computation, but the engine also contains highly concurrent, I/O-bound workloads whose performance is shaped by 99th- and 99.9th-percentile latency. The stated targets include object-storage I/O, distributed cache lookups, replica coordination, and HTTP fan-out.
Approach / What changed
Silk provides stackful fibers with cooperative scheduling, one pinned scheduler thread per CPU, NUMA-aware work stealing, io_uring as the I/O ground truth, and a steady-state hot path without heap allocation. It includes a benchmark harness, GDB extension, and BPF profiler. Fiber stacks are mmap’d from per-fiber pools with guard pages, and runtime containers use intrusive fields.
Takeaways
Silk’s topology-aware stealing orders candidates by estimated cost: hyperthread siblings, same-socket cores, then cross-socket cores, with randomization within each tier.
The reported benchmarks include roughly 3.6 nanoseconds per fiber yield with cross-CPU work stealing, 7.6 microseconds for an io_uring ping-pong, and 5.9 million file IOPS in a working configuration.
At 10,000 concurrent S3-style requests, internal benchmarks reported roughly 65% better 99.9th-percentile latency than an equivalent thread-pool executor, while median throughput was identical.
Source and freshness
- Source
- clickhouse.com
- Published
- Added to Yomu
- Last updated
Summaries are generated from the original by a language model. Check the original before relying on it.
Keep reading
Related reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
The best engineering reads, once a week
One useful email. Unsubscribe anytime.