Rustup 在 Windows 和 NFS 上性能优化的幕后故事：NTFS 并非元凶，效率提升的关键在于精细化系统调用管理和反病毒软件协调

linux.conf.au

引言与Rustup性能挑战 [00:00:16]

主讲人介绍了 rustup，即 Rust 编程语言的安装器，它负责安装 Rust 及其各种组件（包括文档），并支持 Linux、Mac 和 Windows 等平台。

• 初遇性能瓶颈 [00:01:44]
  • 在2019年初的一次差旅中，主讲人在网络环境恶劣的Windows Surface设备上安装 rustup 时，发现安装过程异常缓慢，耗时约3分45秒（不含下载时间）。
  • 在 GitHub 上找到了相关 bug 报告，初步将问题归咎于 NTFS、小文件和反病毒软件，特别是安装文档时速度最慢。

    

  • 尽管最初的报告将问题归咎于防病毒软件，但关闭防病毒软件后，安装速度依然缓慢，这促使主讲人深入调查。

Rustup内部代码优化 [00:05:03]

• 1. 文件操作从“复制”到“移动” [00:05:34]
  • 最初的安装流程在处理完模块数据后，执行的是文件“复制”操作，而非“移动”。
  • 通过将这一小小的操作改为“移动”，安装时间从3分45秒缩短到2分23秒，显著减少了磁盘I/O和电池消耗。
• 2. 减少冗余的 stat 系统调用 [00:08:21]
  • 分析发现，rustup 在提取每个文件时，都会防御性地 stat （获取文件状态）其父目录，以确保它仍然存在。
  • 累计下来，这项操作耗费了大约2秒，节省了20,000次不必要的 stat 调用。
  • 强调 stat 操作并非免费，即使在 Linux 上也会消耗时间。
• 3. 增大tar文件读取缓冲区 [00:09:50]
  • rustup 从磁盘上的 tar 文件中读取数据，然后写入大量小文件。
  • Rust 内置的缓冲区大小为8KB，但操作系统内核通常会调度更大的 I/O 请求，导致低效的 I/O 争用。
  • 通过将 tar 文件读取缓冲区增大，安装时间额外缩短了0到12秒。
• 4. 优化文件时间戳和权限设置 [00:11:20]
  • 通过 Process Monitor 发现，rustup 在安装过程中对每个文件进行了多次冗余的文件操作：
  • stat 文件以检查是否存在。
  • 打开、写入、关闭文件。
  • 再次打开文件，设置访问时间（atime）和修改时间（mtime），然后关闭。
  • 读取文件权限，然后关闭。
  • 设置文件权限，然后关闭。
  • 解决方案 [00:12:48]
  • 首个优化是停止对文件 mtime 的不必要更新，因为对于文档文件，最后修改时间并不重要。这节省了4-6秒的安装时间。
  • 解释了 Windows NT 内核没有直接的 intime 系统调用，而是通过通用文件操作来实现，这增加了操作成本。
  • 强调在 Windows 上，对文件路径进行操作（chmod）是竞争条件（racy）的，不如对已打开文件句柄进行操作安全和高效。

    

Tar-rs库的外部优化 [00:16:22]

• 1. 解决时间检查/时间使用（TOCTOU）安全漏洞 [00:16:38]
  • TOCTOU 漏洞是一种竞争条件，例如先检查文件路径不存在，然后才写入文件，攻击者可以在检查和写入之间插入符号链接，导致写入到意想不到的位置（如 /etc/passwd）。
  • 解决方案是使用原子写入操作（例如 O_EXCL 标志），如果在写入时文件已经存在，则返回错误而不是覆盖。
• 2. 在文件打开状态下设置权限 [00:17:55]
  • 优化了在 Windows、Linux 和 BSD 上设置文件权限的 API 调用，确保在文件打开时执行模式设置，避免了 TOCTOU 漏洞和重复的文件打开/关闭。
• 3. 优化 Windows 上的只读模式设置 [00:18:35]
  • 在 Windows 上，若文件在写入完成后应保持可写状态，则无需额外的系统调用来更改其权限，因为写入时已以可写模式打开。

反病毒软件（Windows Defender）的性能问题 [00:21:12]

• 1. 通过线程池分发 CloseHandle 调用 [00:20:21]
  • 问题：Windows Defender 会在文件关闭（CloseHandle）时扫描文件内容，导致 CloseHandle 调用阻塞，严重拖慢安装速度。
  • 解决方案：将 CloseHandle 操作推迟到独立的线程池中异步执行。这使得 rustup 的主线程不再被阻塞，安装速度降至11秒。
  • 尽管提升了安装速度，但也导致笔记本电脑的 CPU 负载和发热量显著增加，因为将大量扫描工作转移到了后台。
  • 提到 Mercurial 也发现了 Windows 上 CloseHandle 慢的问题，并采取了类似的线程化策略。
  • 解释了 Windows 与 Linux 在脏页（dirty page）处理模型上的根本差异，Windows 的脏页与文件句柄绑定，关闭句柄时会阻塞直到 I/O 完成和驱动程序扫描完成。
• 2. 与微软合作优化 Defender 行为 [00:26:44]
  • 问题：即使通过线程化 CloseHandle 解决了部分问题，Defender 仍在文件写入时立即扫描，对于文档这种不立即使用的文件来说，这是不必要的开销。
  • 主讲人通过 Twitter 联系到了微软的产品经理，并利用 Windows 的“反馈中心”工具提交了详细的性能追踪报告。

    

  • 微软的回应非常积极，最终通过更新防病毒数据库，将 rustup 生成的文件扫描模式从“写入时”改为“读取时”。
  • 这一改变使得 rustup 的安装时间进一步降至约4秒，与 Linux 上的性能持平。

NFS 性能问题及解决方案 [00:31:06]

• 1. 线程化所有文件 I/O [00:32:25]
  • 在 Windows 上的优化完成后，一些在 NFS 挂载的主目录上使用 rustup 的用户反馈安装失败。
  • 追踪发现，NFS 上的 open (3ms)、chmod (2ms)、chown (1ms) 系统调用延迟很高。对于20,000个文件，这些延迟累加起来高达120秒。
  • 解决方案是进一步线程化所有文件 I/O 操作。
• 2. 线程化目录操作并批量分发 [00:32:31]
  • 除了文件 I/O，目录操作也进行了线程化。
  • 在目录操作完成后，批量分发（例如500个）文件 I/O 操作。
• 3. 在提取过程中设置权限 [00:32:44]
  • 将权限设置逻辑整合到文件提取过程中，而不是单独的后续步骤，避免了重复的文件操作。
  • 主线程现在只负责提取，所有其他的权限设置、chown/chmod 操作都在每个 CPU 一个的工作线程中进行。
  • 在 NFS 服务器上，安装时间降至15秒。

    

• 引入 Catapult Trace [00:33:04]
  • 为了更好地分析和调试，引入了一个新的追踪系统，可以输出 Catapult 追踪文件。
  • Catapult 是 Chromium 浏览器性能分析器背后的项目，允许将 rustup 的性能数据可视化，就像浏览器性能追踪一样。

经验总结 [00:33:38]

• 系统调用并非免费 [00:33:49]
  • 无论在 Linux 还是 Windows 上，系统调用都会产生开销。
• 不要将串行代码的性能问题归咎于文件系统 [00:33:55]
  • 糟糕的程序设计和串行操作才是性能瓶颈的真正原因，而非 NTFS 或其他文件系统本身。
• 反病毒软件会使性能问题更加突出 [00:34:05]
  • 反病毒软件在执行其职责时，会放大程序中已存在的效率低下问题。

WSL1 性能挑战 [00:34:15]

• Windows Defender 对 WSL1 的影响 [00:34:30]
  • 最初，Defender 没有扫描 WSL1 进程，因为它识别的是不同的进程名称。
  • 即使禁用 Defender，WSL1 中的 open 和 close 系统调用仍然缓慢。
  • 分析显示，WSL1 中存在一个粗粒度锁定的迹象，导致文件描述符分配和释放的延迟。
  • 一个 HTML 文件的 CloseHandle 调用在 Defender 引擎中耗时12毫秒，因为它涉及文件映射和内容扫描。

    

问答环节摘要

• 关于“恶意邮件”（nasty grams） [00:41:44]
  • 主讲人收到一些不满的声音，因为他在优化 rustup 的过程中获得了微软的“特权访问”。
  • 他的回答是“我只是礼貌地提出了请求”，并强调了在沟通中保持专业和尊重的重要性，用事实说话，而非指责。
• Async 编程模型的作用 [00:43:43]
  • 异步编程模型可能使代码更易读，但并不能解决底层系统调用阻塞的问题。
  • 像 CloseHandle 这样的操作仍然需要在真正的线程中执行，因为内核层没有异步版本。
• 性能优化的普遍性 [00:44:49]
  • 对于像 NPM 和 Yarn 这样的项目，要提升性能，没有“灵丹妙药”，唯一的解决方案是在每一个细节上都极其严谨。
  • 通过并行化操作到工作线程池是提升性能的好方法，但需要管理内存占用和其他资源限制，以避免过度提交或耗尽资源。性能分析是一个漫长、反复试验、不断进化的过程。