Ubuntu Server 运行缓慢的原因与排查

Ubuntu Server（以24.04 LTS Noble Numbat系列及后续点版本为主）在生产环境中“突然变慢”或“持续响应迟钝”是运维最常见的痛点之一。慢的表现形式多样：SSH登录卡顿、命令执行延迟、Web/API响应时间暴增、容器/数据库吞吐下降、负载平均值异常高等。

根本原因几乎总是四大资源之一（或组合）达到饱和或严重争用，导致内核调度、I/O等待或上下文切换开销爆炸。以下按发生概率从高到低排序，并给出系统化的排查思路。

一、常见根本原因分类（概率排序）

1. CPU 争用或调度问题（最常见，~40%案例）
   • 高负载进程/线程抢占（应用bug、爬虫、挖矿脚本）
   • CPU steal 时间高（云VPS超售、noisy neighbor）
   • CPU governor 为 powersave/ondemand，导致频率上不去
   • 高软中断（网络洪水、irq不均衡）
2. 内存压力 + Swap Thrashing（第二大杀手，~25–30%）
   • 内存泄漏或 OOM 前兆（进程不断申请未释放）
   • Swap 使用率飙升 → 磁盘IO爆炸 → 系统整体卡死
   • zram/swapfile 配置不当，或 zram 压缩比过高
3. 磁盘 I/O 瓶颈（尤其是根分区或 /var/lib/docker）
   • 日志/journald 无限增长未轮转
   • Docker/Podman 镜像/容器/volume 堆积
   • 高写负载服务（数据库、日志服务）写满磁盘或预留空间耗尽
   • 硬件问题：SSD过热节流、HDD坏道、NVMe PCIe带宽饱和
4. 网络栈或中断问题（高并发场景常见）
   • 网络拥塞、丢包、TCP backlog 溢出
   • 高软中断（softirq）占用（网络包洪水）
   • DNS 解析慢（导致服务启动/连接延迟）
5. 内核/系统级问题（较少但致命）
   • 内核 bug 或 mitigations 开销（Spectre/Meltdown缓解）
   • cgroup v2 限制过严（容器场景）
   • systemd 服务依赖死锁或启动超时
6. 其他隐蔽原因
   • 过热导致 CPU/GPU/SSD 降频（物理服务器常见）
   • 恶意软件/后门（罕见但需警惕）
   • 配置漂移（旧内核残留、snap 缓存爆炸）

二、标准排查流程（推荐顺序，5–15分钟内定位80%问题）

阶段1：快速概览（30秒–1分钟）

# 1. 整体负载与资源快照
uptime          # load average 数值含义：1/5/15分钟平均运行队列长度
top             # 按1查看每个核，按Shift+M 按内存排序
# 或 htop / btop（推荐安装）

# 2. 内存与Swap使用
free -h         # available 才是真正可用内存
vmstat 1 5      # si/so 列 >0 表示正在Swap

# 3. 磁盘使用与inode
df -hT          # 哪个分区满？
df -i           # inode耗尽？
iostat -x 1 5   # %util接近100% = IO瓶颈

# 4. CPU steal（云环境必看）
mpstat 1 5      # %steal >5–10% 说明宿主机抢CPU

快速判断规则：

• load average >> CPU核数 → CPU争用
• free 显示 available < 总内存10% 或 swap used >0 → 内存压力
• df 显示 / 或 /var >90% → 磁盘满
• iostat %util 高 + await >10–20ms → IO瓶颈
• mpstat %steal 高 → 云超售，考虑升级套餐

阶段2：定位罪魁祸首（2–5分钟）

# 1. 找吃CPU的进程
top / htop → 按CPU排序，看前几名
ps aux --sort=-%cpu | head -10

# 2. 找吃内存/泄漏的进程
top → Shift+M 排序
ps aux --sort=-%mem | head -10

# 3. 找IO占用狂魔
iotop -o        # 只显示有IO的进程（需安装）
# 或 pidstat -d 1 查看每个进程的磁盘读写

# 4. journal 日志空间（常见元凶）
journalctl --disk-usage
du -sh /var/log/*

# 5. Docker/容器相关（如果用了容器）
docker system df
docker stats --no-stream

阶段3：深入诊断特定场景

• 高 steal 时间（云VPS） → 监控一段时间，如果持续>10%，基本是宿主机超售 → 迁移实例或升级规格
• Swap Thrashing → swappiness 降到10（vm.swappiness=10），启用zram（sudo apt install zram-config）
• CPU 频率不上 → 检查 governor：cpupower frequency-info 或 cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor → 服务器场景切换 performance：echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
• 日志/缓存爆炸 → journalctl --vacuum-size=500M 临时清理 → 配置 /etc/systemd/journald.conf 限制 SystemMaxUse
• 网络/中断问题 → sar -n DEV 1 5 看网络吞吐 → cat /proc/interrupts 看中断分布 → softirq 高 → 可能网络洪水或驱动问题

三、预防与长期优化建议

• 安装监控：Netdata（实时仪表盘）或 Prometheus + node_exporter（趋势+告警）
• 关键告警：CPU >90%持续5min、内存available <15%、磁盘>85%、steal>5%、swap used>0
• 定期维护：apt autoremove、journal vacuum、docker prune、snap 清理旧版本
• 云环境：避免低配共享型实例，使用burst或专用型
• 应用层优化优先：索引、缓存、连接池、异步等，通常收益远超系统调参

一句话总结排查思路：

“先看 uptime/top/free/df/iostat/mpstat 四大金刚 → 定位资源饱和类型 → 用 htop/iotop/journalctl/docker stats 深挖进程/服务 → 针对性清理/调参/扩容/迁移”

绝大多数“服务器突然变慢”都能在上述流程中找到根因，极少数才是内核/硬件深层问题。遇到卡死无法登录时，优先通过云控制台或物理KVM查看 top/mpstat。