dial9 就是这样出现的。

hen多工具的诞生，并不是因为“想Zuo个工具”，而是因为问题实在太难查了。

说实话，dial9 这个东西，其实挺有意思的。它不是那种“我今天想Zuo个工具，然后就Zuo了”的那种项目。它geng像是那种——“哎呀，这事儿太难搞了得整个新东西出来kankan”。

下面几个案例，就是它被逼出来的过程。

第一个故事：生产环境里的“隐形杀手”

有人来找我帮忙：他们正在把一个新的 Rust 组件接入现有服务，但碰到了一个非常诡异的性Neng问题。geng麻烦的是这个问题只Neng在生产环境里复现。

原因也hen现实：这个服务会同时连接成千上万个远端主机，这种规模在测试环境里根本模拟不出来。

他们Yi经收集了 Tokio runtime 的各种指标，但这些数据并不Neng解释问题：

这些指标当然有价值，但它们只Neng告诉你“结果”，hen难告诉你“过程”。

于是我们需要一个东西：

这就像给异步运行时装上了一个飞行记录仪。

这类问题Zui大的特点是：聚合指标里你通常只Nengkan到“慢了”，却hen难知道“到底是谁卡住了谁”。

而 dial9 恰好Ke以记录这样一种事件：

它不是只统计数字，而是把底层运行时事件——例如单次 poll、park、wake——按日志一样记录下来。

也就是说你kan到的不再只是“Tokio 有点慢”，而是：

geng关键的是它还会把下面几类信息放到一起：

简单来说dial9 是一个面向 Tokio 的运行时遥测工具。

对于 Tokio 这样的异步运行时来说这种Neng力非常珍贵。

好消息是：dial9 现在就Ke以上手。

它不是让你猜，而是让你直接kan到

hen多团队在大规模使用 Tokio 时确实会碰到一些“kan起来像是 runtime 有问题”的场景。

按理说这不该发生。

但麻烦在于，仅靠聚合指标去推断根因，往往非常依赖经验。你得足够熟悉 Tokio 的内部机制，也得理解操作系统调度、I/O 唤醒、锁竞争等行为，才Neng从一堆零散指标里拼出真正的问题。

而 dial9 Zui打动人的地方，不只是“它Nengkan到geng多数据”，而是它把过去hen多只Neng靠经验和猜测去判断的问题，变成了Ke以直接观察、直接验证的事实。

这在原理上并不难理解。

但即便知道原理，真正kan到 trace 时这种“漂移”的程度依然会让人吃惊。

在一段 trace 中，一个被高亮显示的任务，在 2ms 内竟然先后跑到了 个不同的 worker 上。

Ru果你以为一个 Tokio 任务通常会稳定地待在某个 worker 上执行，那现实可Neng会让你有点意外。

由于 Tokio 的 I/O driver 工作方式，当一个任务在 socket 上等待之后下一次由哪个 worker 把它捡起来继续执行，往往近似随机。再加上 work stealing 的存在任务在 worker 间迁移就会变得非常频繁。

dial9 Nengkan到任务的完整生命周期，以及每一次 poll 的执行位置，所以你Ke以hen直观地观察到：同一个任务会频繁地在不同 worker 之间跳来跳去。

这也解释了为什么hen多数据密集型应用会考虑采用“每核一个 runtime”的架构： 因为它Ke以减少任务跨核迁移带来的 cache line bouncing，从而降低性Neng损耗。

一个真实案例：启动阶段的性Neng问题

另一个案例发生在某个生产服务的启动阶段。

这个团队遇到的问题是：服务启动时 p99 延迟非常糟糕。

他们Yi经收集了 Tokio runtime 的各种指标，但这些数据并不Neng解释问题：

geng奇怪的是系统在 CPU 使用率不到 % 时一直表现正常；可一旦超过这个点，性Neng就会突然崩掉。可问题在于——CPU 明明还没有被完全打满。

把 trace 导进 dial9 之后问题一下就清楚了：

用 dial9 一kan，原因非常明确：当系统在短时间内并发打开大量连接时任务会在 fd_table 扩容期间被取消调度。

这里的 fd_table，负责追踪当前打开的文件描述符。 问题在于，它扩容时需要拿一把锁，而这把锁会卡住所有试图打开新连接的 worker。

这意味着，每个 worker 只要想抓 backtrace，就dou得去争抢同一个 mutex。

在写这篇文章时backtrace::trace 内部会获取一把全局锁。

我原本以为 frame-pointer unwinding 理论上不需要这种全局协调——从技术上说也确实如此——但这个库出于一些实现上的复杂原因，还是会拿这把锁。

于是 trace 里几乎是一眼可见：每一次 poll 还没结束，就因为等待这把锁而被挂起了。

结果就是：

这是一篇 Russell Cohen 的客座文章。 当 Russell 第一次向我展示 dial9 时我立刻觉得：Tokio 社区一定得知道这个工具。于是我邀请他写下这篇文章，并请他在 TokioConf 上Zuo现场演示。 —— Carl

内核调度延迟：一个被忽略的性Neng杀手

先说一个hen容易被忽略、但杀伤力极大的问题：内核调度延迟。

它指的是：

线程Yi经“Ke以运行”了但内核没有立刻让它上 CPU，中间存在一段空档。

也就是说线程明明 ready 了却没被马上执行。

在前面提到的那个 AWS 服务里我们就kan到了大量 10ms 以上的调度延迟。有一段生产环境里的真实 trace 显示：runtime 尝试唤醒 worker ，但内核直到 18ms 之后才真正调度它执行。

这意味着，在这 18ms 内，所有流量dou只Neng由一个 worker 苦苦支撑。

等它真正跑起来以后问题几乎立刻就暴露了：应用存在频繁的 10ms 以上内核调度延迟。而Ru果你的目标延迟本来就只有 –10ms，那这Yi经足以把系统打穿了。

Ru果你的系统目标延迟本身就在几毫秒量级，那这种问题几乎是灾难性的。

主机越忙，这种调度延迟就越容易出现。

dial9 会在 worker park / unpark 时读取内核元数据，因此它Ke以非常精确地kan出：

线程因为等待某个资源而被内核取消调度，并在那一刻抓取调用栈。

自举式调试：dial9 查自己

Zui有意思的，是Zui后这个案例： 我们居然是用 dial9，查出了 dial9 自己内部的性Neng问题。

当时我在给 dial9 增加一个“任务转储”Neng力。思路hen简单：每当某个 future 返回 Poll::Pending 时就抓一份 backtrace，这样开发者就Neng知道它到底是在哪个调用路径上挂起的。

但问题来了：功Neng一打开，开销立刻从 % 飙到 %。而且 worker 越多，情况越糟。

问题完全坐实。

目前我们还在继续推进 task dump 功Neng。 不过在那之前，得先把基于 frame pointer 的栈展开和**backtrace 的 lazy symbolizing**推进到 Tokio 里。

使用 dial9

dial9 Yi经发布到 crates.io，现在就Ke以试用。

根据文章中的描述，dial9 的额外开销通常低于 %。

当然是否适合长期开启，Zui终还是要结合你的业务场景和机器资源Zuo评估。

下面是几个真实案例。

trace 文件会输出到 /tmp/my_traces/ 目录下。你Ke以直接用 trace viewer 打开，把 .bin 文件拖进去就行。项目里也提供了 demo trace，方便先体验一下效果。

同时RotatingWriter 会自动控制磁盘占用，因此你Ke以把它持续挂在生产环境里而不用太担心 trace 文件无限膨胀。

此外dial9 还支持把 trace 直接写入 S3。

第一步：添加依赖

cargo add dial9-tokio-telemetry

对应的 Cargo.toml 配置如下：

dial9-tokio-telemetry = ""

第二步：用 TracedRuntime 包装 Tokio runtime

use dial9_tokio_telemetry::telemetry::{RotatingWriter, TracedRuntime};fn main -> std::io::Result<> { let writer = RotatingWriter::new?; let mut builder = tokio::runtime::Builder::new_multi_thread; builder.worker_threads.enable_all; let = TracedRuntime::build_and_start?; runtime.block_on; Ok)}

就这么简单。

dial9 Zuo的事情不一样：

它不是让你猜，而是让你直接kan到。

而 dial9 的价值就在于：

hen多团队在大规模使用 Tokio 时确实会碰到一些“kan起来像是 runtime 有问题”的场景。

Ru果你正在排查：

那 dial9 hen值得一试。

Zui后也向所有推动 dial9 成为现实的人致敬，尤其是 Jess Izen、Mark Rousskov，以及 AWS 那些Zui早把它跑进生产环境的团队。

TokioConf 见。

---