Linux 系统卡顿问题解决方案-linux运维-PHP中文网

%CPU长期超90%却找不到进程，主因是短生命周期进程干扰或进程名截断；应使用top -b -n 1和ps aux --sort=-%cpu定位，并检查内核线程、shell脚本及I/O、内存、swap真实状态。

linux 系统卡顿问题解决方案

Linux 卡顿最常见原因是某个进程偷偷吃满 CPU，但 top 默认按 CPU 排序时，可能被短生命周期进程（比如 shell 脚本启的临时子进程）干扰，或者进程名太短、被截断，看不出真实身份。

实操建议：

运行 top -b -n 1 | head -20 抓快照，避免交互式刷新掩盖瞬时峰值
用 ps aux --sort=-%cpu | head -15 看更稳定的排序结果，--sort=-%cpu 强制降序且不依赖交互状态
重点关注 ps 输出中 COMMAND 列末尾带 [...] 的进程（内核线程），它们通常不占 CPU，但若出现异常高占用，可能是硬件驱动或内核模块问题
如果看到大量 sh 或 bash 进程 CPU 高，别急着 kill，先用 ls -l /proc//cwd 和 cat /proc//cmdline | tr '\0' ' ' 查它在跑什么脚本

磁盘空间充足 ≠ I/O 不瓶颈。小文件随机读写、日志刷盘、swap 频繁交换都会让 I/O 队列堆积，系统响应变慢，尤其在机械硬盘或低配云盘上更明显。

实操建议：

运行 iotop -oP（只显示实际 I/O 进程 + 只显示有 I/O 的进程），重点看 IO> 列，不是 SWAPIN
检查 /var/log/journal/ 是否过大：systemd-journald 默认不限大小，日志暴涨会引发持续写入，用 journalctl --disk-usage 查，用 journalctl --vacuum-size=200M 限制
确认是否启用 swap：即使内存够，内核仍可能把匿名页换出，用 swapon --show 和 cat /proc/swaps 核对；若非必要，用 swapoff /dev/sdXn 关掉并注释 /etc/fstab 中对应行
SSD 用户注意：vm.swappiness=1 比默认 60 更合理，减少无谓 swap 倾倒

Linux 的“空闲内存”不等于“可用内存”。内核会把大量内存用于 page cache 和 slab 缓存，这部分在需要时可快速回收。但当缓存碎片化严重、或分配大块连续内存失败（如某些驱动、DMA 场景），就会触发直接回收甚至 OOM killer。

Obsidian (Linux)

操作 Obsidian 库（纯 Markdown 笔记），并通过 notesmd-cli 实现自动化。

下载

实操建议：

看 cat /proc/meminfo | grep -E "^(MemAvailable|Buffers|Cached|SReclaimable)"，重点是 MemAvailable —— 它才是内核估算的真正可用量
如果 MemAvailable 远低于 free 显示值，说明 slab 缓存（尤其是 SReclaimable）占了大头，可能是 dentry/inode 缓存未及时释放，常见于大量小文件操作后
临时缓解：运行 echo 2 > /proc/sys/vm/drop_caches（仅清 page cache + slab，不影响运行中进程），但别加到定时任务——治标不治本
长期方案：检查是否有程序泄漏 inotify 句柄或未关闭的 epoll 实例，用 lsof -p | wc -l 对比句柄数是否异常增长

这不是偶然 OOM，而是内存泄漏或资源未释放的明确信号。OOM killer 杀掉的只是“替罪羊”，真正的问题往往藏在被杀进程的上游：比如一个 Python 服务不断 fork 子进程但不 wait，或 Node.js 应用未正确处理 stream 错误导致 socket 积压。

实操建议：

立即执行 dmesg -T | tail -30，找最近一次 OOM 时间点，再用 journalctl --since "2024-05-20 14:22:00"（填你看到的时间）查当时服务日志
用 ps aux --sort=-vsz | head -10 查虚拟内存（VSZ）最大的进程，它未必是 CPU 高的那个，但很可能是泄漏源
对可疑进程，用 cat /proc//status | grep -E "^(VmRSS|VmSize|Threads|SigQ)" 看 RSS 是否随时间缓慢上涨，SigQ 值极大（如 65535/65535）说明信号队列塞满，常因异步处理逻辑卡死
不要只盯着应用层：某些旧版 NVIDIA 驱动、Realtek 网卡固件在特定负载下也会缓慢泄漏 kernel memory，slabtop 里观察 kmalloc-* 或 kmalloc-rcl- 行是否持续增长