开发者用 Claude Code 调优 Ubuntu 笔记本以支持 AI 辅助开发

我在一台运行 Ubuntu 的 Dell 笔记本上写软件。现在大部分工作都交给 Claude Code 来做。它整天跑构建、测试和数据库。十一月的一个周日，我问了它一个简单的问题：这台笔记本能不能做得更好？

我本来以为只需要做些小调整。结果我们发现了真正的问题，还有几个意外。"我们"指的是运行 Opus 的 Claude Code 和我。大部分挖掘工作都是它做的。它不能用 sudo，所以它给我命令让我去执行。以下是我的笔记。

这台笔记本是 Dell Precision 3591，32 GB 内存，1 TB 美光 SSD。显卡是一块小的 NVIDIA RTX 1000 Ada，6 GB 显存。处理器是 Intel Core Ultra 7 155H。它还有一个内置的 AI 芯片，NPU。我从来没用过它。

处理器有 16 核 22 线程。六个核是快的"性能"核。另外十个是慢一些的"能效"核。我之前不知道一颗芯片里的核心可以不一样。这是硬件，不是设置：Intel 从 2021 年起就混合使用这两种核心。快核每个跑两个线程。小核耗电少得多。内核决定哪些工作分到哪里，这一点后面还会提到。

第一个发现是最简单的。磁盘用了 90%，其中一个文件夹占了 431 GB。

那个文件夹里是一个 Rust 项目 Morpholog 的调试构建。Morpholog 是我的开源项目。企业把规则写一次，Morpholog 就拿每一次变更去对照检查。它用 Rust 编写，针对 Postgres 做测试。

Cargo，Rust 的构建工具，会保留它做过的每一次构建。它从不丢弃旧的。每次我切换分支，代码就变了，于是 Cargo 构建并保留一份新副本。几个月下来就把磁盘填满了。

删掉这个文件夹后，磁盘占用从 90% 降到 25%。但它很快就长回来。几个小时内又到了 45 GB。所以我们用 cargo-sweep 设置了一个每晚任务。它会删除 14 天没人用过的构建输出。它还把每个项目的构建文件夹控制在 60 GB 以内。

第二个发现更重要。内核日志里全是这样的行：

nvme nvme0: I/O tag 849 (a351) QID 3 timeout, completion polled

每一行意味着一次 30 秒的卡死。当 SSD 完成一次读或写时，它会发出一个叫中断的信号。在这里，信号丢了。内核等了 30 秒，放弃，然后自己去检查驱动器。答案其实一直在那里。这种情况每次启动发生 5 到 68 次，而且从九月下旬就开始了。

原因是 Intel VMD，即 Volume Management Device。它位于处理器和 SSD 之间。这台笔记本出厂时 VMD 是开着的，处于一种叫 "RAID On" 的存储模式。在 Linux 上，VMD 有时会丢掉驱动器的中断。其他人在别的笔记本上用美光驱动器也遇到过同样的问题。他们通过关闭 VMD 解决了。

九月的时候，我试过一个内核参数 pcie_aspm=off。它会关闭 PCIe 链路的节能，也就是连接 SSD 和 GPU 的通道。它没有帮助。它还有一个副作用，下面会提到。

我不用这台笔记本上的 Windows，所以修复很简单。在 BIOS 里，我把存储模式从 "RAID On" 改成 "AHCI/NVMe"。在这种模式下，Linux 直接和驱动器通信。Ubuntu 像以前一样启动。启动时间从 2 分 10 秒降到 20 秒。之后再也没有出现过超时。而且整台笔记本感觉都更流畅了，不只是构建。每个程序之前都在等同一块磁盘。

我们还检查了驱动器的健康状态。它用掉了额定寿命的 3%。它写入了 37.2 TB，读取了 7 TB，也就是每读一次写五次。几乎所有的写入都是 Rust 构建。

如果你有一台较新的 Intel 笔记本，journalctl -k -b | grep -c 'completion polled' 可以统计本次启动以来的这类卡死次数。

那个旧的内核参数是有代价的。它让 NVIDIA 显卡一直醒着。显卡闲置时也要消耗约 10 W。在笔记本上，这些热量本可以给处理器用。我们移除那个参数后，显卡 97% 的时间都在休眠。

这里还有个小意外。用 nvidia-smi 查询显卡会把它唤醒，因为工具必须和显卡通信。所以我最初的读数显示 GPU 很忙：因为我一直在问。内核自己有记录，读那个不会唤醒显卡。

在一次长时间构建中，处理器温度停在 99 到 100 °C。这让我担心。我最初的读数说核心降到了 1.2 GHz。

那个读数是错的。它把空闲核心也平均进去了，而那些核心按设计就跑得慢。我们改为做一次干净的测试，让每个核心都忙一分钟。快核保持在 2.9 GHz，慢核 2.3 GHz。风扇转速 4200 rpm。对这颗芯片在一台 15 英寸笔记本里来说，这是正常的。没有什么需要修的。

教训：测量正在工作的核心，而不是所有核心。

有些设置对这类工作来说太小或太保守了。

笔记本上的两个 Postgres 服务器都跑在默认配置上。这意味着 32 GB 的机器上只有 128 MB 共享内存。意味着成本估算还是按机械硬盘写的。还意味着 JIT 是开着的。JIT 在运行查询前把它编译成机器码。这对长报表有好处。对测试跑的那些短查询来说，是白费功夫。

我们给 Postgres 分配了 2 GB 共享内存，并告诉它磁盘是 SSD。我们关掉了 JIT，让它为一个查询使用更多核心。一个带 join 和 sum 的测试查询从 605 ms 降到 330 ms。

写入还是一样慢。每次提交都要等到安全写到磁盘上，这个等待决定了节奏。所以，仅对测试数据库，我们关掉了 synchronous_commit。这样 Postgres 在写到磁盘之前就确认提交。崩溃可能会丢失最后零点几秒的数据。它不会损坏任何东西，因为 Postgres 仍然按顺序写日志。提交快了 15 倍：从 0.58 ms 变成 0.04 ms。

我们用来跑基准测试的数据库保留了安全设置。这样它们的数字还能和以前的运行结果比较。

Morpholog 的完整测试跑一遍大约五分钟。大部分时间里，一个核心在工作，21 个在等。数据库测试共用一个数据库，并在开始时把它清空。所以它们只能轮流来。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）