前言

在运维阿里云 Ubuntu 服务器时，偶尔会遇到服务器负载（Load Average）异常飙升，但 CPU 使用率却不高，系统响应极其缓慢的情况。通过 vmstat 和 top 命令观察，发现大量的进程处于 D 状态（不可中断睡眠），且 wa (iowait) 指标极高。

本文将记录一次典型的因系统自动更新服务（unattended-upgrades）导致的持续大量 IO 读问题的排查与解决全过程。

一、问题现象

服务器出现明显的卡顿，业务响应延迟。通过监控和命令行工具观察到以下异常指标：

1. 系统负载与 IO 等待

使用 vmstat 1 查看系统状态，发现 bi (blocks in) 数值极高，且 wa (CPU 等待 IO 完成的时间百分比) 长期维持在 94%-95% 左右，说明系统瓶颈在于磁盘 IO。

root@iZt4n2aetxdzw76gmch8jiZ:~# vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu-------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st gu
 0  8      0   7460    192  74692    0    0 144128    64 3705 3154  0  6  0 94  0  0
 0  6      0   7648    172  74252    0    0 153400     0 5895 7403  0  5  0 95  0  0
 ...

注：b 列表示处于不可中断睡眠状态的进程数，数值较高；wa 列高达 94%，证实 IO 是瓶颈。

2. 进程资源占用

使用 top -d 1 查看进程详情，发现 apt-check 进程占用了大量的 IO 资源，且状态为 D。同时系统负载（load average）高达 26+，远超 CPU 核心数。

top - 10:19:09 up 17:31,  3 users,  load average: 26.14, 25.26, 16.55
Tasks: 130 total,   1 running, 129 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.4 us,  4.9 sy,  0.0 ni,  0.0 id, 94.7 wa,  0.0 hi,  0.0 si,  0.0 st

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
  12501 root      39  19  112980  30656   4736 D   3.9   7.3   0:38.98 apt-check
     50 root      20   0       0      0      0 S   3.1   0.0   7:23.38 kswapd0

3. 详细 IO 统计

使用 pidstat -d 1 进一步确认各进程的读写情况。数据显示 apt-check (PID 12501) 的读取速度高达 84,960 kB/s，远超其他进程。

10:20:07      UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s iodelay  Command
...
10:20:07        0     12501  84960.00      0.00      0.00       0  apt-check
...
10:20:08        0     12501  75096.00      0.00      0.00       0  apt-check

二、根因分析

通过上述排查，可以确定问题的根源是 Ubuntu 系统的 自动更新检查服务。

1. 触发机制：Ubuntu 默认安装了 unattended-upgrades 包，并配置了定时任务（timer）定期运行 apt-check 来检查是否有可用的软件包更新。
2. 资源竞争：当服务器配置较低（如本例中内存仅 407MiB）或磁盘 IO 性能有限时，apt-check 在遍历本地软件包列表并与源服务器对比时，会产生大量的磁盘读取操作。
3. 后果：高频的 IO 读取导致磁盘队列堵塞，CPU 大量时间花在等待 IO (wa)，进而拖慢了整个系统的响应速度，甚至导致 SSH 连接卡顿。

三、解决方案

针对此问题，我们可以通过临时终止进程和永久禁用自动更新两种方式来处理。

1. 紧急处理：停止相关服务与进程

首先，立即停止正在运行的定时任务和升级服务，释放 IO 资源。

# 停止自动更新相关的定时器
systemctl stop apt-daily.timer
systemctl stop apt-daily-upgrade.timer

# 停止未attended升级服务
systemctl stop unattended-upgrades

# 查看服务状态确认已停止
systemctl status unattended-upgrades

# 强制终止占用 IO 的 apt-check 进程
# <pid> 替换为 top 或 pidstat 查到的实际进程 ID，例如 12501
kill -9 <pid>

2. 永久解决：修改配置禁止自动更新

为了防止问题复发，需要修改配置文件，关闭定期的包列表更新和无人值守升级。

步骤：

1. 编辑配置文件 /etc/apt/apt.conf.d/20auto-upgrades：

   vim /etc/apt/apt.conf.d/20auto-upgrades
   

2. 将文件内容中的 "1" (开启) 修改为 "0" (关闭)：

   修改前：

   APT::Periodic::Update-Package-Lists "1";
   APT::Periodic::Unattended-Upgrade "1";
   

   修改后：

   APT::Periodic::Update-Package-Lists "0";
   APT::Periodic::Unattended-Upgrade "0";
   

3. 保存退出后，禁用 unattended-upgrades 服务开机自启：

   systemctl disable unattended-upgrades
   

四、验证与总结

执行完上述操作后，再次使用 vmstat 和 top 观察系统状态：

• wa (iowait) 应显著下降至正常水平（通常 < 5%）。
• apt-check 进程消失。
• 系统 Load Average 逐渐回落。
  

总结

对于低配置的云服务器（尤其是小内存实例），Ubuntu 默认的自动更新机制可能会成为性能杀手。在生产环境中，建议：

1. 手动控制更新：关闭自动更新，选择在业务低峰期手动执行 apt update && apt upgrade。
2. 监控告警：配置对 iowait 和 load average 的监控告警，以便及时发现此类 IO 瓶颈。
3. 资源评估：如果必须保留自动更新，请确保服务器拥有足够的内存和磁盘 IO 能力来支撑后台任务。

---

本文基于实际排查案例整理，希望能帮助遇到类似问题的开发者快速定位并解决故障。