第 3 课 · 进程与资源：top/ps/kill，看谁在吃内存

Linux 基础 · L1 · 第 3 / 6 节 · 约 3 分钟

服务器变慢的第一排查动作不是重启，是看清楚谁在吃资源。这一课教会你用 top、ps、free、df 四件工具回答四个问题：CPU 被谁占了、内存还剩多少、磁盘满没满、怎么安全地终止失控进程。

进程是什么：PID 与父子关系

运行中的程序就是进程，每个进程有唯一编号 PID；进程可以派生子进程（Nginx 主进程带一堆 worker 就是典型）。PID 1 是所有进程的祖先（现代系统上是 systemd）。查进程树：

ps auxf | less        # 全量进程带树形缩进（f 参数画出父子关系）
pstree -p | head -30  # 更直观的进程树
pgrep -a nginx        # 按名字找 PID（-a 带命令行）

top：实时仪表盘怎么读

top        # 进入实时视图；q 退出
# 常用交互键：P 按CPU排序 · M 按内存排序 · k 输入PID发信号 · 1 展开每核

头部三行的读法：load average（1/5/15 分钟平均负载——与核数比：4 核机器 load 4 以下算健康，持续超过核数就是排队）；%Cpu 行的 us（用户程序）/sy（内核）/wa（等 IO——wa 高说明磁盘是瓶颈不是 CPU）/id（空闲）；MiB Mem 行的 free 与 available——看 available 不看 free：Linux 会把空闲内存拿去做磁盘缓存（buff/cache），需要时立刻还给程序，available 才是真实余量。

ps 与精确过滤

ps aux --sort=-%mem | head -8    # 内存大户前 8 名
ps aux --sort=-%cpu | head -8    # CPU 大户前 8 名
ps -o pid,ppid,user,%cpu,%mem,etime,cmd -p 某个PID   # 单进程详情（含运行时长）

free / df / du：内存与磁盘的两本账

free -h                # 内存：重点看 available 列与 Swap 使用
df -h                  # 各挂载点的磁盘余量（Use% 到 90% 就该处理）
du -sh /var/log/* | sort -rh | head    # 谁在吃磁盘：日志目录常是第一名
du -xh / --max-depth=2 2>/dev/null | sort -rh | head   # 全盘大户扫描（-x 不跨文件系统）

磁盘满的连锁反应比内存满更凶险：日志写不进、数据库拒绝写、SSH 登录都可能失败——df 看到 90%+ 立即找大户（通常是日志与缓存），清完再想扩容。

kill：终止进程的信号分级

kill 12345        # 发 SIGTERM(15)：请进程自己收尾退出——永远先试这个
kill -9 12345     # 发 SIGKILL(9)：内核直接抹掉——数据可能损坏，最后手段
kill -HUP 12345   # 发 SIGHUP(1)：多数守护进程的解释是「重读配置」
pkill -f 关键词    # 按命令行关键词终止（小心匹配面，先 pgrep -f 预览）

纪律：TERM 等十秒，不走再 KILL——数据库与带缓存的服务被 -9 直接抹掉，轻则丢缓存重则坏数据文件。终止系统关键进程（systemd 管理的服务）的正确姿势是 systemctl stop 服务名，让管理器知道状态。

综合排查：一次「机器卡」的完整流程

# ① 负载与 CPU：load 是否超核数、wa 是否高
top -bn1 | head -5
# ② 内存：available 还剩多少、Swap 是否在猛用
free -h
# ③ 磁盘：余量与 IO 大户
df -h / && du -sh /var/log /tmp 2>/dev/null
# ④ 找出大户并处置（先确认它是什么再动手）
ps aux --sort=-%mem | head -5
# ⑤ 处置后复测①②③——数字回落才算解决；反复出现则查它为什么失控

IO 等待：第三种瓶颈的识别

CPU 高与内存满之外，第三种「机器卡」的元凶是磁盘 IO 瓶颈，特征是 top 里 wa（iowait）占比高而 us/sy 不高——CPU 在空等磁盘。确认与定位两步：iostat -x 1 5（sysstat 包）看每块盘的 %util（接近 100% 即饱和）与 await（平均 IO 等待毫秒数，机械盘几十毫秒正常、固态盘超过个位数就该注意）；iotop（需要装）直接列出谁在读写。典型场景：日志疯狂刷盘（应用报错循环）、备份任务撞上了业务高峰、机械盘跑数据库。处置口径：先停掉可停的（备份挪窗口）、再治本（报错循环修应用、数据库迁固态）——「重启解决」在 IO 瓶颈上通常只是清空了队列，十分钟后原样复发。

长期观察：给自己建一条监控基线

排查工具都是「现场看」，而多数性能问题有前兆——磁盘以每天 1% 的速度爬向 100%、内存占用周级缓涨（泄漏的典型曲线）。不装监控系统的最小方案是一条 crontab：*/10 * * * * echo "$(date +\%F\ \%H:\%M) $(df -h / | awk 'NR==2{print $5}') $(free -m | awk '/Mem/{print $3}') $(uptime | grep -o 'load average.*')" >> /var/log/baseline.log——每 10 分钟记一行「时间磁盘% 内存MB 负载」，一个月后 tail -100 或丢进表格画图，趋势一目了然。有监控需求的下一步是 Prometheus 类系统，但在第一台服务器上，这条 cron 就是性价比最高的「监控」。

本节小结

负载看 load 与核数的比值、内存看 available 不看 free、磁盘看 df 的 Use%；
kill 分级：TERM 请退、KILL 强杀，中间隔十秒；托管服务用 systemctl；
「机器卡」的排查是固定五步：负载→内存→磁盘→大户→复测，每步都有命令。