ScyllaDB 学习(二) – seastar 简介
seastar
是 ScyllaDB
使用的框架,从官网介绍可以看到 seastar
是为现代硬件设计的高性能框架。
Seastar is an advanced, open-source C++ framework for high-performance server applications on modern hardware.
High-level Goals
什么是现代硬件呢?先来看几张图,图来自 Under the Hood of a Shard-per-Core Architecture。
单核的性能已经进入平稳期,CPU 朝着数量越来越多发展,其他硬件发展也很快,盘的容量、吞吐和 IOPS 越来越高,网络也不再是瓶颈,而传统架构的软件已经无法很好的利用现代硬件资源。seastar
就是因此设计的,它的目标是(来自 ScyllaDB: No-Compromise Performance):
- Efficiency:
- Make the most out of every cycle
- Utilization:
- Squeeze every cycle from the machine
- Control:
- Spend the cycles on what we want, when we want
Efficiency 指充分利用每个 CPU cycle,获取尽可能高的 IPC,也要避免资源浪费,只把资源用在有用的地方,包括避免 memory copy、cache coherence、context switch、locking 等。Utilization 是因为大部分软件的单机扩展性都不好,无法利用到大型机器的所有 CPU、IO 资源,只能用小型机器或者拆分进程,企图用集群的扩展性掩盖单机扩展性的问题,但进程实例越多,也意味着故障发生的概率越高、更难运维,所以 seastar
目标是单个进程内也是随资源线性扩展的。Control 是因为系统内通常会有各种 background jobs 和 foreground jobs 竞争资源,比如 compaction,所以 seastar
目标是能控制任务的资源使用,实现 self-tunning/workload-conditioning 从而获取 consistent latency。
Shared-Nothing/Shard-per-Core
想要利用好现代硬件,就要 no locks/shared-memory/synchronization/context-switches/memory-copies,seastar
给出的答案是 shared-nothing 或者叫 shard-per-core 架构,单个进程也像分布式一样做 sharding 从而获取线性扩展性。
shard-per-core 不是简单的创建核数个线程,再把每个线程 pin 在一个核上就结束的,有很多问题要解决。
Asynchrony, Everywhere
因为每个线程都是完整的工作单元,需要处理茫茫多的执行流,所以不能有阻塞得是纯异步的,coordination 开销也要尽可能小。seastar
实现了 futures, promises, and continuations (f/p/c) 来提供更好的抽象和开发体验。
Memory
memory 越来越大,但 CPU 和 memory 的性能差距也越来越大,memory I/O 很可能成为系统瓶颈,这个问题随着核数的增多也越来越明显,CPU 使用率高也不代表在工作(CPU Utilization is Wrong)。NUMA 就是优化这个问题的一种办法,它把 CPU 和 memory 分成多个 zone(node),不同 zone 之间互联,单个 zone 内的 memory I/O 很快但跨 zone 就很慢,这也导致未针对 NUMA 架构优化的程序在 NUMA 下性能表现不佳。
想要利用好 NUMA 就要避免跨 zone 的内存访问,除此之外,由于 seastar
架构的特殊性,现在的内存分配库里的线程同步都是没必要的,所以 seastar
实现了自己的内存分配器,每个线程会独占一部分内存(会考虑 NUMA)进行分配和释放,从而避免同步和实现 NUMA friendly。当需要共享内存时,seastar
为每对线程都创建了 spsc 无锁队列用于消息通信。
Kernel
即使用户程序实现了 shared-nothing,但 kernel 是基于 shared-memory 实现的,并不非常 scalable:
- Networking stack:在 Linux posix 网络协议栈下,一个网络包可能会经过 3 个 CPU 才能真正被应用线程处理到:处理硬件中断的 CPU -> 处理软件中断的 CPU -> 处理该 socket 的 CPU,而且用 socket 接口必然会发生 memory copy,所以
seastar
除了 posix 协议栈外也提供了用户态协议栈,使用 DPDK 来传输数据。 - Disk I/O:
seastar
要纯异步自然就只能用异步 I/O,因为是 14 年开始的项目,当时 Linux 下唯一的选择就只有 AIO,AIO 只能用 direct I/O,所以需要自己实现 cache,不过 page cache 是由操作系统管理的,用户态程序缺少控制,既是线程安全的也不能避免 memory copy(非 mmap),本身就不在seastar
考虑范围内。 - Control:
seastar
想要能控制所有任务的 CPU、I/O 资源使用,所以基于 control theroy 实现了 CPU&I/O scheduler。CPU scheduler 可以在 future executor 实现。Linux I/O scheduler 因为无法精细控制请求优先级、reorder/merge 导致延迟不稳定等原因也被禁掉了(使用 noop),ScyllaDB
会自动 benchmark 当前 disk 获取最佳的并发度用于调优用户态 I/O scheduler。
参考资料
- ScyllaDB: No-Compromise Performance 20 年在 CMU DB 课上的分享,但不完整,看了下和 17 年 InfoQ 上的分享大致一样。
- Under the Hood of a Shard-per-Core Architecture 介绍 shard-per-core 架构需要解决哪些问题。
总结
只能说搞底层的人就是牛逼,一言不合 bypass kernel,但是 full control of the software stack 确实带来了非常大的收益。
留下评论