Linux 进程管理与系统监控：ps、top、systemctl 与服务器变慢排查顺序

把 Linux 当成服务器用，迟早会遇到「怎么突然变卡了」的时刻。是 CPU 跑满？是内存不够在狂用交换分区？还是磁盘 IO 堵了？能不能快速定位「是哪个进程在捣乱」，直接决定了你几分钟还是几小时解决问题。这篇文章把进程管理与系统监控的常用命令串成一套可照做的排查流程。

一、看清进程：ps 与 top

第一步是「看见」正在跑的进程。ps 是快照式查看，ps aux 以 BSD 风格列出全部进程并带 CPU、内存占用，ps -ef 则是标准风格、父子关系（PPID）更清楚。想实时盯着变化就用 top，它会持续刷新，按 CPU 或内存排序帮你一眼锁定吃资源的进程；htop 是 top 的增强版，支持鼠标、彩色、树状视图，但通常需要额外安装。新手记住：top 里看着最占 CPU 的那一行，往往就是你要处理的对象。

二、内存与磁盘：free / df / du

卡顿常常不是 CPU 而是内存或磁盘。free -h 看内存，重点看 available 而不是 free——available 才是真正还能拿来用的量，free 很小未必有问题（Linux 会拿空闲内存做缓存）。df -h 按挂载点看磁盘使用率，哪个分区快满了立刻现形。du -sh /var 则能算出一个目录总共占多大；配合 du -h --max-depth=1 / 可以逐层找出是哪个目录吃掉了空间。这三件套，是定位「空间去哪了、内存够不够」的标配。

三、杀进程与调优先级：kill / nice

找到捣乱的进程，下一步是控制它。kill 默认发 SIGTERM（15）礼貌地请进程退出，kill -9 则是 SIGKILL 强制杀死（进程来不及清理，慎用）。按名字杀可以用 pkill -f nginx 或 killall httpd。如果某个任务太占资源，可以用 nice -n 10 tar ... 以低优先级跑，或用 renice 调整已在运行的进程。要强调的是，kill -9 是最后手段，优先尝试普通 kill 让程序自己收尾。

四、systemd：现代 Linux 的服务管家

现在的主流发行版几乎都用 systemd 来管理服务。最常用的就是 systemctl：systemctl start/stop/restart nginx 启停重启，systemctl enable --now nginx 设开机自启并立即启动，systemctl status nginx 看运行状态。查日志用 journalctl -u nginx -f，-u 指定单元、-f 实时跟随、--since "1 hour ago" 看某时段。systemd 用「target」取代了老式的运行级别（比如 multi-user.target 约等于以前的 runlevel 3），它最大的好处是服务挂了能自动重启、日志统一归集，比老的 SysV init 省心太多。

五、服务器变慢，按顺序查这五步

真正实战时，我建议你固定一套顺序，别东一榔头西一棒槌。第一，uptime 或 top 看负载平均值（load average 的 1/5/15 分钟值），判断整体忙不忙；第二，top 里看是哪个进程吃 CPU；第三，free -h 看内存是不是吃满、是不是在频繁换页（swap 狂涨＝内存不足）；第四，iotop 或 iostat 看磁盘 IO 是不是瓶颈（%util 接近 100% 就说明盘忙死了）；第五，iftop 或 ss -tnp 看网络吞吐和连接数。这套「负载→CPU→内存→磁盘→网络」的顺序，能帮你在一分钟内把问题缩小到具体层面。

六、用 systemd 写个自己的服务

前面讲的都是管别人的服务，那如果你想让自己写的一个小程序也能开机自启、挂了自动重启，该怎么办？答案就是写一个 systemd 服务单元。假设你在 /opt/myapp 放了一个长期运行的脚本，只需在 /etc/systemd/system/myapp.service 里写几行：指明 ExecStart 指向你的启动命令、Restart 设为 always、User 指定运行账户，然后 systemctl daemon-reload、systemctl enable --now myapp，它就成了一个正经的系统服务，和 nginx 享受同等待遇。这比用 nohup 甩到后台专业太多，也是把玩具脚本变成生产服务的关键一步。

再进阶一点，你可以给服务加上资源限制，比如 MemoryMax 限制它最多用多少内存、CPUQuota 限制 CPU 占比，防止某个失控的脚本把整台机器拖垮。还能用 OnFailure 指定它失败时去触发告警脚本。systemd 把进程管理从一堆手工命令，升级成了一整套可声明、可约束、可观测的服务治理框架——这也是为什么现代 Linux 发行版都义无反顾地投奔了它。

排查服务问题时，journalctl 是你的好朋友。除了 -u 服务名 -f 实时跟随，还可以 --since 与 --until 精确拉取某段时间的日志，-p err 只看错误级别，_PID= 按进程号过滤。配合 systemctl status 里给出的最近几行日志，绝大多数服务起不来的原因都能在五分钟内定位。建议新手把这几条 journalctl 命令设为肌肉记忆。

还有一个实用心法：当你发现某个进程 CPU 或内存异常，先别急着 kill，用 systemctl status 或 ps 看清它的父进程是谁、因什么而起，顺着依赖链往往能找到真正的病根——比如是某个定时任务反复拉起它，还是配置错误导致它崩溃重启循环。治标更要治本，这正是进程管理从会杀进程走向懂系统的分水岭。

进程管理与监控，是把一台会卡顿的机器变成可控系统的关键能力。很多人在服务器变慢时只会重启了事，而懂了负载、内存、磁盘和网络这套排查顺序的人，往往几分钟就能定位到是哪个进程在捣乱，从而对症下药而非盲目重启。这种能力一旦养成，你在运维路上就少了一分慌乱、多了一分底气。更进一步，当你学会用 systemd 把自己的脚本也变成受管服务，你就不再只是一个命令的使用者，而开始像一个系统的设计者那样思考：什么东西该自动重启，什么东西该被限制资源，什么东西该留下日志。这种从被动救火到主动治理的转变，正是普通玩家和专业人员之间最真实的分界线，也值得你在这上面多花一些功夫去刻意练习，因为真正的能力从来都是在一次次排错里长出来的。

掌握进程管理之后，你面对服务器时会多一份笃定。无论它多么繁忙多么反常，你都知道该从哪里下手去还原真相，而不是慌乱地盲目重启。这种从现象追溯本质的能力，是区分业余与专业最明显的标志，也最能体现一个运维者的真实功底。请务必把那套排查顺序刻进肌肉记忆，它会在你最需要的时刻自动浮现，帮你把一次次危机化解于萌芽。与此同时，学会用 systemd 托管自己的程序，意味着你开始用工程的眼光组织运行环境，而不只是在命令行里东敲西打。当你的脚本也能像系统服务一样被监控被拉起被记录，你就已经走在从使用者迈向建设者的路上了。这条路没有捷径，但每一步都算数，愿你走得踏实而笃定，也愿每一次排错都成为你积累经验的养分而非负担。

把这套能力练扎实，你便能在任何一台陌生的机器面前都保持镇定，而这正是运维这条路上最宝贵的资产。愿你在每一次深夜的告警里，都能从容地顺着线索走到真相的尽头，而不是被困在表面的慌乱之中，因为你早已知道该先去看负载、再看内存、继而磁盘与网络。

#Linux进程 #ps #top #systemctl #journalctl #服务器监控 #排查