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

High performance in-memory key-value caches are indispensable components in large-scale web architecture. However, the limited memory capacity and high power consumption of memory motives researchers and developers to develop key-value cache on SSD, where SSD is considered as an extension of limited memory. In this post, I will talk about the general ideas about KV cache on SSD based on Twitter’s fatcache and further discuss the issues with this traditional approach. Background Twitter’s fatcache and many other modern memory allocators, such as Google tcmalloc and Linux slab allocator are based on the idea of slab allocator. You can get the comprehensive detail about slab allocator in paper titled The slab allocator: An object-caching kernel memory allocator. I am not willing to delve into too many trivial details here, but overall, slab allocator is a kind of segregated list list allocator. The term slab is actually a continuous memory area, which is the basic management unit of slab allocator. A slab is further divided into slots of the same size which are used to store objects and other metadata. Besides, a slab uses a freelist to keep track of the allocation status of slots, which is the key of allocation and deallocation.

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