深入掌控进程：ps、nice、kill 与后台秘籍

52JinY 助手

谈进程管理这件事，很多人第一反应是“这不就 ps、kill 两下的事吗？”真到线上机器出事，才知道命令会用不难，难在理解背后的语义、选择合适的力度，别一刀把业务砍死还以为自己英雄救火。

先说 ps。常见的 ps aux 与 ps -ef 本质是两套输出格式，前者更贴近 BSD 风格，后者是 SysV 风格。我的习惯是配合 grep 和列对齐工具：ps aux |

grep -E '进程名|端口号'，再用 awk 截列，快速定位 CPU、RSS 异常的家伙。遇到线程型服务，我更依赖 ps -Lfp  看每个轻量级线程的占用，再配合 top -H 或 pidstat -t 把热点线程捞出来，用 jstack/gstack 对应线程 ID 做进一步分析。另一个小技巧是用 --sort=-%mem,-%cpu 直接排序，别被“看起来很安静”的父进程骗了，真凶常常是某个子进程或线程。

说到 nice，很多人把它当成“限速器”，但要记住 nice 值越高，表示“越客气”，优先级越低。线上

情况下，我更倾向用 renice 动态调低一类“可延迟”的任务，比如批量日志压缩、离线报表，把它们调整到 10~15，让交互式或在线请求的线程呼吸顺畅。别指望 nice 解决一切，CPU 抢不过去还好说，遇到 I/O、锁竞争，nice 几乎帮不上忙。这时应该思考是否要做 cgroups 或 ionice 的配合控制，或者干脆把任务切到另一台专门的批处理节点。

kill 的学问在于层级与节奏。我的默认流程是先发 SIGTERM（15），给进程一个体面收尾的机会，观察 5~10 秒是否释放端口、落盘完毕；若进程卡在不可中断 I/O（D 状态），你再怎么 TERM 都没用，要从根因下手，比如文件系统卡顿或远端 NFS 抖动。确认无业务影响窗口后，才会升级到 SIGKILL（9）。还有一个容易忽视的点：别只杀父进程。用 pstree -ap 或 ps --ppid 把子进程梳理清楚，必要时对进程组发信号（kill -TERM -），避免“野孩子”继续占资源。对于需要触发核心转储排查的顽疾，

我会用 kill -QUIT 或者给特定服务的“优雅退出”信号，既不粗暴停机，又能拿到堆栈与状态，后续复盘有据可依。若要核心转储，别忘了调整 ulimit -c 与 /proc/sys/kernel/core_pattern，很多人以为“没生成 core 是程序没挂”，其实是系统策略把它吃掉了。

后台任务这块，最怕“以为在跑，实际上早就僵了”。nohup 加 & 只是把标准流丢到文件并脱离终端，谈不上守护。更靠谱的做法是用 setsid 或 daemon 化，配合 systemd、supervisor 之类的进程管理器，给出明确的 Restart 策略、资源限制与健康检查。临时排障时，我会在 shell 里用 () 子进程 + &

把长任务包起来跑：({ 命令; echo $$ > /tmp/job.pid; }) &，同时用 disown 脱离当前 shell，避免断线带崩会话。输出别全怼进 nohup.out，按日期切分日志，或者直接把 stdout/stderr 接到 logger，再由 journald/rsyslog 接管，查问题省事得多。需要临时观测资源占用，可以用 time -v 或 /usr/bin/time 记录峰值内存与上下文切换，给后续调参提供量化依据。

还有两类坑值得单拎。其一是僵尸进程，ps 里看到 Z 状态别慌，它们不占 CPU/内存，只是父进程没 wait 回收。解决思路是修父不修子：修代码补 wait，或先优雅退出父进程，让 init 接盘再回收；直接 kill 僵尸一般无效。其二是孤儿进程与会话领头进程，使用 kill 时注意控制边界，tmux/screen 里跑的任务、或者被 sudo 切换过用户的进程，信号可能发不到位，必要时用 setsid 启动并针对进程组施加信号，或者结合 cgroup.freeze 做“定格”排查。

进程管理的终局，往往不是花里胡哨的命令组合，而是标准化。给每个服务一份清晰的 unit 配置：明确 ExecStart/Stop、Restart=on-failure、LimitNOFILE、KillMode=process，配合 RuntimeMaxSec 防止悬挂；批处理任务落到定时器或编排器，不再依赖 crontab+nohup 的土法。指标侧，把进程数、线程数、上下文切换、FD 使用率、RSS/Swap 告警都接入监控，用导出器抓 /proc 与 cgroup 指标