记一次使用Claude Code 优化Ubuntu 24.04开发机踩坑过程

共计 8646 个字符，预计需要花费 22 分钟才能阅读完成。

日期： 2026-03-08
系统： Ubuntu 24.04
硬件： Intel Xeon E5-2686 v4（18 核 /72 线程）/ 64GB DDR4 ECC / NVIDIA GTX 1060 6GB / NVMe 931GB
用途： 本地开发机

一、故障排查：桌面会话崩溃

1.1 问题现象

问题描述：运行大量应用程序约 2 小时后，回到电脑时需要重新登录，疑似系统重启。

1.2 排查过程

第一步：确认是否真正重启

last reboot | head -5

reboot   system boot  6.8.0-101-generi  Thu Mar  5 08:03   still running
reboot   system boot  6.8.0-101-generi  Mon Mar  2 20:23 - 23:21 (2+02:57)

结论：上次会话（Mar 2 → Mar 4）以正常 systemd-poweroff 结束， 并非崩溃重启 ，当前开机已持续运行 3 天多。说明 " 需要重新登录 " 不是系统重启，而是桌面会话本身崩溃。

第二步：查找桌面会话崩溃原因

sudo journalctl --since "2 hours ago" -p warning | grep -E "killed|session|gdm|crash"

在 2026-03-08 17:02 发现关键日志：

gdm-x-session[4279]: Segmentation fault at address 0x10
gdm-x-session[4279]: Fatal server error: Caught signal 11 (Segmentation fault). Server aborting
gdm-x-session[4279]: 崩溃位置：/usr/lib/x86_64-linux-gnu/nvidia/xorg/libglxserver_nvidia.so
org.gnome.Shell@x11.service: Main process exited, code=killed, status=9/KILL

崩溃链条：

GPU 高负载（大量应用运行）↓
libglxserver_nvidia.so 内部 NULL 指针解引用（Segfault at 0x10）↓
X Server 收到 SIGSEGV → 强制终止
    ↓
GNOME Shell 被 SIGKILL
    ↓
GDM 重新显示登录界面 

第三步：查明 NVIDIA 驱动版本冲突

dpkg -l | grep nvidia | awk '{print $2, $3}'

发现系统同时存在两个不同版本的组件：

nvidia-driver-535          535.288.01   ← 主驱动
nvidia-firmware-580-580    580.126.09   ← 固件（版本不匹配！）

这是导致 libglxserver_nvidia.so Segfault 的根本原因：驱动与固件版本不一致，在 GPU 高负载时触发内部错误。

同时发现历史日志中存在大量 DRM 报错（早在 Mar 2 就已出现）：

kernel: [drm:nv_drm_master_set [nvidia_drm]] *ERROR*
[nvidia-drm] [GPU ID 0x00008400] Failed to grab modeset ownership

第四步：排除其他硬件问题

1.3 解决方案

升级 NVIDIA 驱动至 580，使驱动、固件、库版本全部统一：

sudo apt install -y nvidia-driver-580
sudo reboot

升级后：

• 驱动版本统一为 580.126.09
• 历史大量 DRM Failed to grab modeset ownership 报错消失
• 重启后 MCE 错误频率显著下降

二、硬件监控工具安装

排查过程中发现系统缺乏硬件监控，一并安装：

sudo apt install -y rasdaemon smartmontools memtester
sudo systemctl enable --now rasdaemon

三、VSCode APT 源配置

问题： VSCode 之前通过手动下载 deb 安装，无法自动更新。

排查： 检查 /etc/apt/sources.list.d/ 目录，确认无 Microsoft 源。

解决：

# 导入 Microsoft GPG 密钥
wget -qO- https://packages.microsoft.com/keys/microsoft.asc \
  | gpg --dearmor \
  | sudo tee /etc/apt/keyrings/microsoft.gpg > /dev/null

# 添加 apt 源
echo "deb [arch=amd64 signed-by=/etc/apt/keyrings/microsoft.gpg] \
  https://packages.microsoft.com/repos/code stable main" \
  | sudo tee /etc/apt/sources.list.d/vscode.list

# 更新并升级（1.109.5 → 1.110.1）sudo apt update && sudo apt install -y code

此后 sudo apt upgrade 即可自动更新 VSCode。

四、开机服务清理

4.1 排查方法

# 列出所有开机自启服务
systemctl list-unit-files --state=enabled --no-pager

# 对可疑服务逐一检查状态
systemctl is-active <service>

发现 126 个已启用的系统服务中，有多个在开发机场景下完全不必要。

4.2 禁用服务详情

物理机不需要的服务：

sudo systemctl disable --now \
  cloud-init cloud-config cloud-final cloud-init-local \
  spice-vdagentd kerneloops

用户不需要的服务：

sudo systemctl disable --now \
  xrdp-sesman gnome-remote-desktop ModemManager rsync \
  apport fwupd
systemctl --user mask ubuntu-report.path
systemctl --user disable --now tracker-miner-fs-3

保留的服务（用户确认需要）：

• avahi-daemon：局域网设备发现（打印机等）
• nmbd / smbd：Samba 文件共享
• mysql / nginx / php8.3-fpm / redis：Web 开发环境
• docker / libvirtd / qemu-kvm：容器和虚拟机
• kcptun / openvpn / privoxy：代理 /VPN

4.3 用户自定义服务清理

发现过期的 qmd-update 定时任务（用户确认不再需要）：

systemctl --user stop qmd-update.timer
rm ~/.config/systemd/user/qmd-update.timer
rm ~/.config/systemd/user/qmd-update.service
systemctl --user daemon-reload

4.4 gnome-keyring 报错说明

日志中存在以下报错， 不影响使用 ：

Failed to add PIDs to scope's control group: No such process

原因：gnome-session 启动 gnome-keyring 子进程时，进程完成速度过快，systemd 来不及将其加入 cgroup scope。这是 Ubuntu 24.04 上 GNOME + systemd 的已知兼容性问题。实际 gnome-keyring 守护进程运行正常，密码 /SSH key 功能不受影响。

五、内核参数调优

5.1 内存管理

问题： 默认 vm.swappiness=60 意味着系统在内存还很充裕时就开始将页面换出到磁盘。对于 64GB 内存的开发机，这会造成不必要的磁盘 IO 和程序响应延迟。

调整：

vm.swappiness=10          # 仅在内存使用超过 90% 时才考虑 swap
vm.dirty_ratio=15         # 内存中脏页超过 15% 才强制写盘（原为 20%）vm.dirty_background_ratio=5  # 后台写盘阈值（原为 10%）

5.2 inotify 文件监视

问题： 默认 fs.inotify.max_user_watches=8192，VSCode、JetBrains IDE、Webpack 等工具在监视大型项目时会报错：

Error: ENOSPC: System limit for number of file watchers reached

调整：

fs.inotify.max_user_watches=524288   # 支持监视约 50 万个文件
fs.inotify.max_user_instances=512    # 支持更多 inotify 实例 

5.3 TCP 网络栈

问题： 默认 TCP 参数为通用场景设计，对 Docker 容器间通信、微服务本地调用、大量并发连接的场景存在瓶颈。

调整及原因：

net.core.somaxconn=65535          # 提升 listen() 的最大连接队列，避免高并发时连接被拒
net.core.netdev_max_backlog=65535 # 网卡收包队列，避免突发流量丢包
net.ipv4.tcp_max_syn_backlog=65535 # SYN 半连接队列，防止连接建立阶段丢弃
net.ipv4.tcp_fin_timeout=15       # TIME_WAIT 超时从默认 60s 缩短到 15s，加快端口回收
net.ipv4.tcp_tw_reuse=1           # 允许复用 TIME_WAIT 状态的连接（用于客户端）net.ipv4.ip_local_port_range=1024 65535  # 扩大本地端口范围，支持更多并发连接
net.core.rmem_max=134217728       # 接收缓冲区上限 128MB（原 212992）net.core.wmem_max=134217728       # 发送缓冲区上限 128MB
net.ipv4.tcp_rmem=4096 87380 134217728  # TCP 接收缓冲自动调整范围
net.ipv4.tcp_wmem=4096 65536 134217728  # TCP 发送缓冲自动调整范围 

5.4 关闭 Core Dump

问题： 程序崩溃时内核默认会在当前目录生成 core 文件，大型程序（如 Chrome、JVM）崩溃时 core 文件可达数 GB，迅速占满磁盘。

kernel.core_pattern=/dev/null   # 崩溃时丢弃 core dump

5.5 应用配置

# 配置文件：/etc/sysctl.d/99-dev-performance.conf
sudo sysctl -p /etc/sysctl.d/99-dev-performance.conf  # 立即生效，重启后自动加载 

六、CPU 调速策略

问题： 默认 schedutil 调速器根据 CPU 负载动态调整频率，在负载突然升高（如启动编译任务）时存在 100~300ms 的频率爬坡延迟，对构建速度有影响。

检查当前状态：

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
# 输出：schedutil

解决： 创建 systemd 服务在开机时将所有核心设为 performance 模式：

# 配置文件：/etc/systemd/system/cpu-performance.service
sudo systemctl enable --now cpu-performance.service

• Xeon E5-2686 v4 基础频率 2.3GHz，Turbo 最高 3.0GHz
• performance 模式固定在最高频率，消除频率爬坡，编译 / 构建任务响应更快
• 代价：空闲时功耗略高，开发机可接受

七、磁盘 IO 调度器

问题： 默认所有磁盘使用 mq-deadline 调度器，对不同类型磁盘未区分优化。

检查当前状态：

cat /sys/block/nvme0n1/queue/scheduler  # [none] mq-deadline
cat /sys/block/sda/queue/scheduler      # none [mq-deadline]

调整策略及原因：

持久化配置： /etc/udev/rules.d/60-io-scheduler.rules，重启自动应用。

八、开机动画（Plymouth）

问题： splash 参数启用 Plymouth 开机动画，在 bootloader 到登录界面之间增加约 5 秒等待。对开发机毫无必要。

修改 ​ ​/etc/default/grub​​ ：

# 修改前
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
# 修改后
GRUB_CMDLINE_LINUX_DEFAULT="quiet"

sudo update-grub

九、/tmp 使用内存（tmpfs）

问题： 默认 /tmp 使用磁盘存储。编译构建、单元测试、Docker build 等操作会产生大量临时文件，频繁的磁盘 IO 影响速度。

解决： 在 /etc/fstab 中将 /tmp 挂载为 tmpfs（内存文件系统）：

tmpfs  /tmp  tmpfs  defaults,noatime,nosuid,nodev,size=8G  0  0

• 64GB 内存，分配 8GB 给 /tmp，剩余 56GB 供应用使用
• noatime：不记录访问时间，减少内存写操作
• nosuid,nodev：安全加固，防止 /tmp 中执行 SUID 程序

十、systemd Journal 日志限制

问题： systemd-journald 默认无大小限制，在运行时间较长的开发机上日志会持续增长，最终可能占用数十 GB 磁盘空间。检查时发现日志已占用 1.0GB。

配置文件： /etc/systemd/journald.conf.d/dev.conf

[Journal]
SystemMaxUse=2G        # 日志总占用不超过 2GB
SystemKeepFree=5G      # 确保磁盘至少保留 5GB 空闲
MaxRetentionSec=30day  # 超过 30 天的日志自动清理 

十一、DNS 优化

问题： 原系统仅配置单个 DNS 服务器 114.114.114.114，单点故障时 DNS 解析失败会导致开发工具（npm、docker pull、git 等）卡住。

配置文件： /etc/systemd/resolved.conf.d/dns.conf

[Resolve]
DNS=114.114.114.114 223.5.5.5      # 主 DNS：电信 114 + 阿里 DNS
FallbackDNS=8.8.8.8 1.1.1.1        # 备用：Google + Cloudflare
Cache=yes                           # 启用本地缓存，重复域名解析秒返回
DNSStubListener=yes                 # 启用 127.0.0.53 本地存根监听 

十二、⚠️ 操作失误记录

12.1 /etc/fstab 意外清空

过程： 执行以下命令时，awk 输出通过管道写入临时文件，但后续 mv 命令失败，原文件已被 tee 清空：

# 危险操作（勿用）：以原文件为输入，同时重定向输出到临时文件
sudo awk '!seen[$0]++' /etc/fstab | sudo tee /etc/fstab.tmp && sudo mv /etc/fstab.tmp /etc/fstab

恢复方法： 通过 blkid 获取所有分区 UUID，手动重建 fstab，并用 findmnt --verify 验证：

sudo blkid                    # 获取所有分区信息
sudo findmnt --verify         # 验证 fstab，输出 "Success, no errors or warnings"

当前 fstab 挂载点：

12.2 Clash Verge TUN 模式失效

过程： 重启 systemd-resolved 时 DNS 链路短暂中断，Clash Verge 检测到异常后自动将 enable_tun_mode 置为 false，TUN 网卡消失，代理失效。

恢复方法： 在 Clash Verge GUI 中手动重新打开 TUN 模式开关。

12.3 操作规范（教训）

修改任何关键系统配置前，必须先备份原文件：

sudo cp /etc/fstab /etc/fstab.bak.$(date +%Y%m%d_%H%M%S)
sudo cp /etc/default/grub /etc/default/grub.bak.$(date +%Y%m%d_%H%M%S)

关键配置文件清单：
/etc/fstab · /etc/default/grub · /etc/sudoers · /etc/ssh/sshd_config · /etc/hosts · /etc/apt/sources.list

十三、优化效果总结