netpoller 概述 考虑一个基于 goroutine-per-connection 模型的 TCP echo server： import ( "fmt" "io" "log" "net" ) func worker(conn net.Conn) { defer conn.Close() b := make([]byte, 512) for { size, err := conn.Read(b) if err == io.EOF { break } if err != nil { log.Fatal(err) } size, err = conn.Write(b[0:size]) if err != nil { log.Fatal(err) } } } func main() { listner, err := net.Listen("tcp", "127.0.0.1:8080") if err != nil { log.Fatal(err) } for { conn, err := listner.Accept() if err != nil { log.Fatal(err) } go worker(conn) } }从用户侧看，系统该调用阻塞 goroutine，Go scheduler 调度其他 goroutine。问题在于，goroutine 复用在线程上，如果 IO 系统调用（如read(2

Motivation FaaS 环境下存在大量短生命周期的函数，这些函数作为进程调度到 OS 上。同时创建数千个函数都是家常便饭。由于 Faas Function 生命周期通常很短，研究表明 99% 的 Azure Function 都在 224s 以内。因此，OS 调度策略会对 FaaS function 的周转时间（turnaround time）产生重大影响。然而，Linux CFS 在大量短生命周期任务的 FaaS 下表现并不好。 论文开发了一个 OS 调度器 ALPS，用函数的历史运行数据预测未来的负载，并模

这个工作太神奇了，阅读 Understanding, detecting and localizing partial failures in large system software 的时候，在思考怎样检测 silent semantic violation，论文里说一个难点就是不知道正确的语义是什么，我想到也许可以用 LLM 推测。完全没想到可以用论文如此简洁的方式推测。 论文的思路很简单，从系统的 regression test 入手。尽管这些 test 通常是真的特定的 bug 的，但这些 test 仍然蕴含了系统的语义。论文要做的就是从 regression test 中推导出这些语义，并在运行时检测系统是否违背了

本论文从最基本的单体数据库出发，一步步推导出目前主流的架构设计，并详细对这些设计进行性能分析。 对于我这种新人而言，跟着作者的思路走，像是一场思想旅行，打开了一扇大门。 Q&A 论文针对哪种类型的数据库？ storage-disaggregated OLTP database 为什么 storage-disaggregated OLAP database 不使用 log-as-the-database 和 shared-storage 设计？ OLAP 通常服务读密集型负载，这两个设计解决的是写密集型负载的痛点。 log-as-the-database 的原理和效果？ 计算节点只发送 xlog，存储节点通过重放 xlog 得到数据。

背景 partial failure 是区别于 fail-stop 模型 full failure 的另一种故障模式，简而言之，partial failure 指系统部分地故障，但不是完全故障而无法服务。论文给 partial failure 下了以下定义： 对于一个服务器进程 P，其中包含许多组件，提供一系列服务 R。如果进程 P 中发生了故障（fault），但这个故障没有让 P crash，但却破坏了 $R_f \notin R$ 安全性（safety）保证、活性（liveness）或性能问题，这样的故障就是 partial

Motivation 目前分布式系统中的故障注入不够高效，主要是由于以下原因： 许多故障是 partial failure。发生故障时，系统仍然在运行，只是系统的某个组件或服务受影响。 故障的触发条件非常罕见。例如，某些故障只在特定时刻的特定网络故障下发生，并且只影响某个组件。 成熟的分布式系统有比较好的容错性。许多混沌工程的实践随机注入故障，成熟的分布式系统可以容忍大部分故障，大量的注入是无效的，