做 Linux 运维和开发久了你会发现系统里最绕不开、最常出问题、也最容易被讲得像玄学的东西就是进程。很多人刚开始学的时候死记 PID、父子进程、僵尸进程背得很辛苦一上了生产环境还是不知道怎么用。我自己带过不少新人也排查过一堆奇奇怪怪的线上问题最深的体会是进程这东西单点知识不值钱关键在于把“概念、原理、工具、实战”串成一条线。这篇我就用一篇文章的篇幅把 Linux 进程从底层概念到排障实战完整捋一遍你照着这条线走至少以后看到进程相关的问题心里不会慌。1. 从“程序文件”到“运行实体”先把进程的底层逻辑搞明白1.1 进程不是程序而是程序的“运行现场”很多人第一次接触进程时都会把进程和程序混为一谈。其实它们的差别非常本质程序是存放在磁盘上的静态代码和数据的集合它不占 CPU 不占内存进程是程序加载到内存之后、由内核创建的一个动态运行实体。说得再直白一点程序是菜谱进程是按照菜谱下厨做饭的过程。菜谱放在书架上一直不会变但厨房里的火候、锅里的菜、操作的人手忙脚乱的过程才是真正的运行态。内核为了管理进程必须给每个进程配一份“档案”这就是进程控制块PCBProcess Control Block。在 Linux 里这个档案结构叫task_struct它是内核中最重要的数据结构之一。里面记录着进程的 PID、PPID、状态、优先级、打开的文件描述符、内存地址空间、信号处理方式、定时器等一堆信息。你平时用ps看到的那些字段几乎都来自这份档案。我经常用这个类比给新人解释操作系统就像一个大型公司的行政管家每个进程是公司的员工PCB 是员工的员工档案。管家不可能天天追着每个员工看它只需要看档案就知道谁在干活、谁在摸鱼、谁请假了。内核也一样它调度进程的时候不看进程的“身体”只看task_struct。再说内存布局。一个进程的内存地址空间从低地址到高地址大体分为代码段、数据段、堆、内存映射区、栈、内核空间。理解这个布局对排查问题非常关键。比如你写 C 语言的全局变量存在数据段用malloc申请内存堆会向上增长函数调用和局部变量栈会向下增长动态库和mmap映射的文件在堆和栈之间的映射区。为什么有些进程会报段错误很多时候就是越界访问了不属于自己的段。为什么内存泄漏难查因为堆不断往上长但没人回收最终撞到映射区。1.2 生命周期与状态流转每个阶段都有对应的运维现象进程从创建到消亡大概会经历这几个状态运行态R、可中断睡眠态S、不可中断睡眠态D、停止态T、僵尸态Z。你用top看到的STAT列就是这些状态的缩写。我挑几个最常说的状态细讲一下。运行态R代表进程正在运行或排队等待运行这个状态本身不稀奇。可中断睡眠态S最普遍进程在等待某个事件比如等用户输入、等网络数据只要收到信号就能醒过来。不可中断睡眠态D就特殊了进程正在等待某种内核资源的 IO 完成比如磁盘读写。这个状态下进程不完全响应信号因为如果中途打断它IO 数据可能就乱了。生产环境里你可能会看到一堆 D 状态的进程通常意味着磁盘或存储系统出了问题比如 NFS 挂死了这时进程杀不掉只能重启对应的服务或者恢复存储。僵尸态Z是新手最容易困惑的。一个进程运行完了它并没有立刻完全消失。它先进入僵尸态意思是父进程还没来得及调用wait()系统调用回收它的退出信息。僵尸进程不占 CPU、不占大部分内存但它仍然保留在进程表里占用一个进程槽位。如果父进程是个没写wait的糟糕程序僵尸进程就会一直堆积把 PID 耗尽新进程起不来。这个我会在后面的排查部分专门讲怎么处理。另外Linux 里还分内核线程和用户进程。内核线程是内核创建的比如kswapd0、kworker它们没有独立的用户态地址空间主要负责内存回收、异步 IO 等内核工作。用户进程则是我们平时用ps看到的那些业务进程。如果你在系统里看到一个进程的 PID 是 2叫kthreadd它就是所有内核线程的“祖先”相当于内核线程的母体。2. 进程的诞生与消亡fork、exec、孤儿和僵尸背后的故事2.1 fork 和 exec一个负责“复制”一个负责“换脑”在 Linux 下创建一个新进程的方式很特殊先调用fork()再调用exec()往往是其中一个系列。有人会问为什么不能一步到位直接按程序路径创建进程这是 Unix/Linux 的经典设计——刚 fork 出来的子进程其实是父进程的完整副本它继承了父进程的内存映像、文件描述符、环境变量等一切。这种设计让系统的进程管理逻辑统一、简洁代价就是复制成本高。后来 Linux 用写时复制Copy-on-Write解决了这个问题fork 的时候只复制页表不复制实际内存只有当父子进程真的要写入某块内存时内核才把这块内存复制一份。这样 fork 的代价大大降低。理解了 fork就理解了父子进程的关系。父进程 fork 出一个子进程子进程从 fork 返回处继续执行返回值不同父进程拿到子进程的 PID子进程拿到 0。代码里通常分成两个分支if (pid 0) 代表子进程干活else 代表父进程等待。exec 系列函数则负责给新进程“换脑”。fork 出来的子进程内存里还是父进程的代码必须通过 exec 加载一段全新的可执行文件替换掉当前进程的正文段、数据段、堆和栈让子进程变成完全不同的程序。也就是说fork 负责生孩子exec 负责给孩子换身份。你在 shell 里执行/usr/bin/python3这条命令shell 先 fork 自己然后子进程 exec 成 python3 解释器整个过程大约不到一毫秒但内核要经历好几个关键步骤。这里有一个实际的坑如果父进程创建了大量子进程每个子进程都瞬间 exec 一个大程序你可能观察到系统负载很高。这就是 fork 风暴常见于应用内部疯狂创建线程、或者定时任务像心跳一样每个周期都拉起一堆子进程。要养成的习惯是排查这种问题时先看ps -ef的父子关系再做时间和数量上的统计而不是盲目重启。2.2 孤儿进程被收养僵尸进程没人管进程退出也有讲究。当父进程比子进程先退出子进程就成了孤儿进程。孤儿进程不会被丢在大街上内核会把它的“收养权”交给 1 号进程init 系统现在是 systemd1 号进程会负责回收它们。所以孤儿进程一般不会积累这是内核的兜底机制。僵尸进程则反过来子进程先退出父进程还在但父进程没有调用 wait() 获取子进程的退出状态。子进程的 task_struct 里还留着退出码、资源使用统计等信息等着父进程来取父进程不来它就一直在进程表里赖着。你说的“杀僵尸进程”其实是个伪命题——僵尸进程已经死了kill -9对僵尸没有任何作用因为它已经不需要信号了。真正要做的是让它的父进程处理善后最简单粗暴就是把父进程也杀掉僵尸会被 init 或 systemd 收养并回收。生产环境里见过最离谱的案例是一个监控 agent 的老版本有个 worker 线程崩溃后会不断 fork 出子进程执行云命令但父进程没有妥善 wait结果一段时间后整个节点 PID 耗尽SSH 都登不进去只能靠控制台重启。从那以后我对所有长期运行的服务都要求必须处理好 SIGCHLD 信号或者用非阻塞 wait绝对不能让僵尸堆积。2.3 进程 vs 线程内核眼里它俩都叫 task“进程和线程有什么区别”是面试高频题但在 Linux 内部线程其实就是轻量级进程都用clone()创建内核调度单位也是 task。区别在于线程和同进程的其他线程共享地址空间、文件描述符等资源进程之间各自独立。用ps -eLf可以看到每个线程的 PID 和线程号 LWP用top -H可以按线程维度看 CPU 占用。排障时线程视图极重要。某个 Java 进程 CPU 跑满光看进程 PID 只会知道是 java 进程不知道具体是哪个线程的问题必须top -H -p PID找到线程号再做printf %x\n 线程号转成十六进制去jstack对应的 nid 里查。这套操作我至少带人做过几十遍基本属于 Java 服务排查必修课。Linux 不对线程做特殊处理反而是排查的好处——所有 task 一视同仁你可以通过/proc/pid/task目录把线程信息全部摸透。3. 看清每个进程从 ps 到 /proc你能掌握的所有细节3.1 命令行五件套ps、top、pidstat、pstree、pgrep想要一眼看到系统里有哪些进程ps是最基本的命令。但很多人只是死记参数集合我推荐一组真正够用的用法ps -ef显示所有进程完整信息UNIX 风格适合看 PID、PPID、CMD 关系。ps auxBSD 风格适合看 CPU、内存百分比。ps -eLf显示进程和线程关系每线程一行适合排查多线程应用。ps -o pid,ppid,stat,wchan:30,comm自定义输出wchan表示进程在内核里等待什么经常能一针见血地看出阻塞点。top负责动态监控。打开后大写 M 按内存排序大写 P 按 CPU 排序大写 H 显示线程小写 c 显示完整命令行小写 o 可以过滤进程名。这些都是基本操作但很多人不会看 load average。系统负载高不一定是 CPU 忙也可能是 D 状态的进程阻塞在 IO 上。uptime显示的三分钟、五分钟、十五分钟负载要和 CPU 核数、进程状态结合起来看。pidstat是 sysstat 包里的工具按固定间隔轮询每个进程/线程的 CPU、内存、IO 情况。比 top 的优点是可以连续采样并看到趋势比如pidstat -p PID 1每一秒输出一次该进程的 CPU 占用pidstat -d 1看进程的读写速率。排查 CPU 忽高忽低的问题pidstat -u 1 10比眼睛盯 top 靠谱得多。pstree看父子进程树特别直观尤其排查那种多级子进程到底是谁拉起来的问题。pgrep -f 关键词可以按完整命令行找进程比如pgrep -f java.*gateway能精确匹配到目标进程避免误杀。3.2 /proc 文件系统内核给每个进程开的“实况直播间”/proc不是普通文件它是内核暴露运行信息的虚拟文件系统每个 PID 对应一个目录。我平时最常用的几个/proc/pid/status最核心的状态文件。State字段看进程状态PPid看父进程Threads看线程数VmRSS看实际占用物理内存voluntary_ctxt_switches和nonvoluntary_ctxt_switches看上下文切换。/proc/pid/fd进程打开的所有文件描述符。里面不仅仅有普通文件还有 socket、管道、设备文件。ls -l看这些链接指向能定位到进程正在使用哪些资源这也是lsof的数据来源之一。/proc/pid/cmdline进程启动时的完整命令行参数之间用\0分隔直接用tr \0 转换后看。/proc/pid/cwd进程的当前工作目录。某些程序找不到相对路径文件或者磁盘卸载不了可能就是因为有进程的 cwd 在那个目录里。/proc/pid/io进程的磁盘读写字节数。排查“哪个进程在疯狂写盘”时连续采样这个文件对比就能定位。/proc里也藏着一个排障利器/proc/pid/stack。普通用户可能没有权限但 root 下可以直接看到进程在内核中的当前调用栈对于排查 D 状态、卡在内核里的进程非常有效。比如一个进程持续 D 状态cat /proc/pid/stack看到它卡在哪一个内核函数基本就能判断是文件系统、块设备还是网络栈的问题。3.3 进程优先级与 nice 值为什么你“杀不死”一个 CPU 满跑的任务进程优先级由nice值和实时优先级共同决定。普通进程的 nice 值范围是 -20 到 19数值越大优先级越低、越“谦让”越小越抢占。你用nice -n -10 command可以启动一个高优先级命令用renice -n 5 -p PID修改正在运行进程的 nice。top 里NI列就是 nice 值PR是内核实际调度优先级。有一个经典场景线上有某个 CPU 密集型的批处理任务占满了所有核业务接口响应变慢。你第一反应是 kill 掉那个进程但发现 kill 后没效果因为批处理进程可能不是完整体面的或者它不断 fork 出孙子进程。这时候你不用盲目 kill直接用renice把它调到 nice 19让它把 CPU 让给核心业务等业务高峰期过了再调回去。这种“软处理”在产线上比强杀更稳妥。同时要说明白实时优先级比普通 nice 值高得多生产环境尽量别随便设置 SCHED_FIFO 或 SCHED_RR一旦一个实时进程忙等 CPU普通进程可能完全得不到调度系统直接卡成假死这种状态连 SSH 都难响应。4. 进程间通信管道、信号、共享内存到底该选谁4.1 管道最简单的“流动”通道管道是最古老的 IPC 方式本质上是一个内核缓冲区一方往里面写一方从里面读按字节流顺序流动。匿名管道只能用于父子进程或有亲缘关系的进程之间因为创建后需要继承文件描述符没有亲缘关系的兄弟进程拿不到同一根管道的两端。你写 Shell 的时候ps -ef | grep nginx这里的竖线背后就是管道shell 先创建管道再 fork 出左右两个命令左命令的 stdout 接到管道的写端右命令的 stdin 接到管道的读端。命名管道用mkfifo创建表现为一个文件但数据不落盘依旧走内核缓冲区。它的一大优势是可以在任意两个不相关的进程间通信比如一个数据采集程序往FIFO里写一个消费者程序从同一个 FIFO 里读。注意坑是默认打开 FIFO 时读写双方必须同时在场否则会一直阻塞。要防止阻塞可以在打开时用非阻塞标志或者让双方约定好生命周期。管道的瓶颈是效率不高每次系统调用都要在内核态和用户态之间拷贝、切换传递大量数据时 CPU 开销明显。但它简单、安全、无需考虑并发锁适合做命令组合和轻量数据流。4.2 信号别把 kill 理解成“杀死”很多人把kill命令当成“杀进程”其实它的本意是“发送信号”。kill -9 PID只是发送 9 号信号 SIGKILL。信号是进程间通信里最轻量也最粗暴的一种方式内核用信号来通知进程“发生了某件事”。常见的信号和含义必须记牢。SIGINT2终端 CtrlC 触发的终止信号进程可以捕获取而做一些清理工作。SIGTERM15默认终止信号kill PID发送的就是它进程可以处理优雅退出信号就是它。SIGKILL9强制终止信号进程无法捕获、无法忽略、无法阻塞内核直接回收。SIGHUP1终端挂断时发出许多守护进程用它来重载配置比如 Nginx 收到 HUP 会重新加载配置文件。SIGCHLD17子进程状态改变时发给父进程父进程可以在信号处理里调用 waitpid 回收子进程这是编写稳定多进程服务的必备信号。写后台服务时最常踩的坑是滥用 SIGKILL。我的建议是优先用 SIGTERM给进程留出处理善后的时间比如刷新日志、断开数据库连接、释放锁否则下一个进程启动时可能发现资源没释放干净。只有进程处于 D 状态、或者死循环完全不响应其他信号时才考虑 SIGKILL。4.3 System V IPC 与共享内存性能与复杂度不可兼得System V IPC 包括共享内存、消息队列、信号量。共享内存可以说是效率最高的 IPC 机制因为它免去了内核态和用户态的数据拷贝多个进程把同一段物理内存映射到自己的地址空间直接读写。典型的实现方式是用shmget创建一段共享内存然后shmat附加到进程。它的问题也很突出多个进程同时写会互相踩踏必须配套信号量做同步而且共享内存的生命周期不跟随进程进程崩了共享内存段依然存在需要ipcrm -m手动清除。POSIX 消息队列是 System V 消息队列的改进版支持按优先级取消息但使用场景相对小众。我猜你的项目里大概率不会直接用这么底层的 IPC除非你在写高性能中间件。大多数现代服务现在都改用本地 Socket、gRPC、或者一个中间件Kafka、Redis来做跨进程通信因为免去了自己处理同步和生命周期管理的麻烦。但从原理角度理解共享内存在对付 OOM、页缓存的问题时很有帮助。4.4 从进程通信到网络通信Unix Socket 和 TCP 的取舍进程在同一台机器上通信Unix Domain Socket 往往比 TCP 更高效。它同样基于 socket 接口但它不走网络协议栈不需要 IP 和端口直接在内核内部搬运数据延迟低得多处理器开销也小。比如 Nginx 和 PHP-FPM 通信时就常用 Unix Socket 而不是 127.0.0.1:9000。调试 Unix Socket 可以用socat或nc -U也可以用lsof -U查看当前有哪些进程在使用。如果进程分布在多台机器上就必须选 TCP 或更上层的通信协议。TCP 有连接管理、可靠传输、流量控制但也会引入大量额外问题连接数膨胀、TIME_WAIT、半连接队列满、网络延迟放大。很多排障场景最后都归结到“是不是连接没关闭”上所以排查进程问题时要学会用ss -anp查看某个进程的所有网络连接这一步和查进程本身同样重要。5. 深入进程内部探针strace、gdb、perf、ftrace 的高阶组合拳5.1 strace对进程的一次“录音”strace可以跟踪进程发起的每次系统调用和收到的每个信号。它是排查“进程卡在某一步”的神器。比如一个进程能启动但一直不出来你不知道它在等什么直接strace -f -p PID观察如果看到它持续阻塞在一个read()或poll()上你就知道它在等某个文件描述符看到它在反复open()某个路径你就知道它在找某个文件找不到。常用参数组合-f跟踪子进程-e tracenetwork只跟踪网络相关调用accept、connect、read对应 socket-tt显示时间戳-o 文件输出到日志。线上临时的 strace 进程本身也会消耗资源建议只在低峰期、短时间采样不要长时间挂。有个典型案例某服务每隔几分钟就出现一个长耗时请求。用strace -f -p 主PID -e tracewrite -tt -o /tmp/net.log观察发现长耗时出现在一个write()系统调用上而且每次写入的字节数都不小。进一步查发现是日志框架同步刷盘把磁盘 IO 的毛刺直接拖进了请求链路。把日志改成异步后长耗时现象消失。这就是好的排查路径先定位系统调用再结合 IO 分析。5.2 gdblive 调试进程的唯一正解当进程不是“卡住”而是“崩溃”或者你想看它当下的内存状态gdb是最靠谱的工具。线上调试分两种情况第一种进程已经崩溃生成了 core dump。gdb 可执行文件 core文件进去后输入btbacktrace查看崩溃时的调用栈基本一眼就能看出崩溃点在哪里。但生产环境默认不开 core dump忘了开就等于失去了第一手证据。建议在/etc/security/limits.conf里设置* soft core unlimited并用 sysctl 设置kernel.core_pattern指向一个固定的 dump 目录配上文件名格式比如/data/core/core.%e.%p这样只要出问题就能留下现场。第二种进程还在运行你想挂上去看它此刻的行为。gdb -p PID可以把进程停下来执行thread apply all bt查看所有线程的调用栈。这个操作非常强大但也会让进程完全冻结线上必须谨慎最好在业务低峰期操作。我见过有人在大促时对线上做gdb -p正好命中高并发请求造成大面积超时教训相当惨痛。调试 C/C 程序时gdb 还能配合info threads、frame、up/down等命令把某个变量的值、某层调用的参数全部翻出来。如果是 Javagdb 的适用性就不如jstack好用但遇到 Java 进程本机崩溃时gdb 看 hs_err 文件里的原生栈依然有帮助。5.3 perf topCPU 时间都去哪了perf是 Linux 性能剖析的瑞士军刀我们日常用得最多的是perf top和perf record perf report。当你发现某台服务器 CPU 使用率很高但用top只能看到是哪个进程不知道到底代码哪一行在烧 CPU 时perf top -p PID会直接以采样方式告诉你 CPU 在哪些函数、哪些符号上消费时间。对 C/C 程序函数符号会出现在输出里比如某个热函数占了几成的采样比例一眼就能定位到热点。对 Java 程序则复杂一些JIT 后的函数和解释执行的部分会混在一起通常需要结合perf-map-agent或者用 JFR 做分配采样。但对内核态的问题perf 依然价值巨大你能看到是页表管理、spinlock、还是内存回收占用了大量 CPU。实际排查案例某海量查询服务高峰期 CPU 满跑perf top 显示热点集中在一个带锁的哈希表操作上几乎所有 CPU 都耗在锁竞争和缓存 miss。后来把锁换成读写锁并扩大分桶性能立刻提升好几倍。这种问题没有 perf 根本无从下手。5.4 ftrace 与内核事件给进程行为打开“上帝视角”ftrace 是内核自带的跟踪器可以跟踪函数调用、事件、延迟。排查那些“用户态看起来没事但系统很卡”的诡异问题ftrace 往往能给出答案。常见操作包括查看当前的追踪器cat /sys/kernel/debug/tracing/current_tracer设置某个追踪函数echo function current_tracer然后写想要跟随的符号到set_ftrace_filter使用trace-cmd record和trace-cmd report记录和分析。实际操作里我更多是通过/sys/kernel/debug/tracing/trace文件和trace-cmd来捕捉函数调用序列。比如怀疑进程被某个持有锁的线程长时间阻塞ftrace 可以记录锁的获取失败路径。ftrace 属于较深的内核工具普通业务排查不一定需要。但有一步操作强烈建议学会查看进程切换事件。echo 1 /sys/kernel/debug/tracing/events/sched/sched_switch/enable然后读取 trace就能看到哪个进程被调度器切换出来、切换原因是什么。这个对于定位周期性的 CPU 争抢、核间迁移问题非常有效。6. 站在 cgroup 之上看进程容器和现代运维中的进程约束6.1 用 cgroup 精准限制进程资源传统运维里一个失控进程把整台机器 CPU 打满、内存耗尽其他进程只能遭殃。现代 Linux 使用 cgroupcontrol group来做资源隔离和限额。cgroup v2 是当前推荐的版本统一在/sys/fs/cgroup下管理。假设我要限制某个进程组最多使用 2 个 CPU 和 1GB 内存可以这样操作。首先创建一个 cgroup 目录mkdir /sys/fs/cgroup/apps写入 CPU 和内存限制echo 200000 100000 /sys/fs/cgroup/apps/cpu.max echo 1073741824 /sys/fs/cgroup/apps/memory.max然后把进程 PID 加进去echo PID /sys/fs/cgroup/apps/cgroup.procscpu.max的第一个数值是配额第二个是周期单位都是微秒。200000/100000 意味着在 100ms 的周期内最多使用 200ms 的 CPU 时间对应两个核心的算力。配额可以超过 100比如 500000/100000 表示 5 个核心。memory.max是硬限制超出后进程组内的进程可能被 OOM 杀掉。现代容器引擎这里泛指容器技术都会用到 cgroup。但很多人在容器里看不到 cgroup 限制的作用因为容器进程本身看到的是宿主机的/proc/meminfo而实际上它被限制在 cgroup 里。排查“容器内内存明明够用却一直在杀进程”的时候要优先想到是不是 cgroup 的 memory.max 设得比实际可用内存小很多。6.2 PID 空间与共享 PID namespace容器隔离的另一个重要视角是 PID namespace。进程在 PID namespace 里看到的 PID 是 namespace 内的 PID而在宿主机上看到的是全局 PID。每个 namespace 有自己的 PID 编号空间从 1 开始。这意味着一个进程在容器内 PID 可能是 42但在宿主机的 PID 可能是 2048。排查容器问题时如果拿宿主机的 PID 去容器里找肯定找不到反之亦然必须做换算。PID namespace 也和 1 号进程的角色有关。容器内 1 号进程必须是能正确处理信号的进程最好是应用进程本身因为容器里没有 systemd。如果你的容器像映射表那样复用了宿主机的启动流程并且容器内 1 号进程不处理 SIGTERM那容器停机时业务进程可能收不到终止信号直接被强杀导致数据丢失。在实际工作里要养成的习惯是遇到和进程有关的问题先确认自己是在容器里还是在宿主机上然后统一用宿主机视角看全局 PID再进对应的 namespace。nsenter可以进入某个已有进程的 namespace命令是nsenter -t 目标PID -m -u -i -n -p-t指定目标进程 PID后面按需进入挂载、UTS、IPC、网络、PID namespace。这个工具是排查容器内进程和宿主进程关系的桥梁。6.3 OOM 机制与进程内存杀手当系统内存不足时内核会启动 OOM Killer根据oom_score选择最该杀的进程。每个进程的/proc/pid/oom_score反映它的“被杀优先级”分数越高越容易被杀。一般规律是占用内存多的进程、badness 评分高的进程更容易被血祭。你可以用echo -1000 /proc/pid/oom_score_adj来保护关键进程把它从 OOM 候选名单里摘掉。但这个操作不适合长期使用因为如果所有进程都不可杀系统最终会死机。生产环境里OOM 背后的原因往往不是真的“物理内存不够”而是某个进程泄露了内存或者页缓存被冲刷得过于激进。排查时不要只盯着free -h看空闲内存而要具体看哪些进程的 RSS 在持续增长。用top -o %MEM排序然后用pidstat -r 1跟踪某个进程的内存增量连续观察几分钟如果 RSS 只增不减基本可以判定有内存泄漏。OOM 被杀后会留下一条带 PID、进程名、内存消耗的记录在dmesg -T或/var/log/messages里能看到。我见过一个依靠内存缓存的中间件频繁被 OOM查了 dmesg 才发现是同一个进程每天凌晨内存占用量冲顶后来通过设置oom_score_adj保护策略和限制缓存上限解决。7. 实战回归用一条链路搞定线上进程排查难题7.1 CPU 打满是谁在作怪假设某天监控报警一台 32 核服务器 load average 刷到 50 以上业务接口基本不可用。你登录上去先别急着杀进程按下面的链路分析。第一用top -c看整体负载和进程列表按大写 P 排序找出 CPU 占用最高的进程 PID。比如看到 PID 是 2234进程名是worker_prod。第二确认这是不是线程级别的消耗。执行top -H -p 2234如果看到只有一个线程的 CPU 接近 100%那就说明不是多线程普遍占用而是单一热点线程。记下这个线程的 LWP 编号例如 2257。第三用cat /proc/2234/status查看该进程的线程数、内存、信号信息再用/proc/2234/task/2257/目录确认线程的 cmdline 和上下文切换次数。第四如果是 Java 或 Python 等应用接下来做进程内部转储。Java 执行jstack 2234 | grep -A 20 nid0x...其中 nid 是十六制的 2257Python 可以py-spy dump --pid 2234。看到线程卡在哪一行代码、哪个字符。第五如果应用层看不出问题用perf top -p 2234或者perf record -p 2234 -g -- sleep 10分析热点的函数名。如果热点在某个加锁代码上就检查锁竞争如果热点是垃圾回收线程就检查堆配置和 GC 日志如果热点是kmalloc、copy_user_enhanced_fast_string之类内核函数那就是用户态内存拷贝和内核态分配太多了。这套链路走一遍我基本都能把 CPU 问题的范围从“整机”缩小到“某一代码块”。关键不在某一个命令而是顺畅地把进程视图、线程视图、内核视图衔接起来。7.2 进程卡死先看状态再看栈“服务没反应了但进程还在”这个现象太常见了。我建议第一步永远是用ps -ef看进程状态。如果状态是 S 或 R说明进程还在正常调度多半是业务逻辑卡死在线程等待上。如果看到一堆 D 状态先处理存储。如果看到 Z 状态处理父进程。针对 S 状态的卡死最有效的武器是cat /proc/PID/stack和cat /proc/PID/task/*/stack。内核栈显示的是该线程在内核中的等待位置。比如卡在pipe_wait说明它在等管道的读写卡在futex_wait_queue_me说明它在等一把应用层的锁卡在inotify_read说明它在等文件系统事件。这些信号非常明确直接引导你往对应方向排查。对于用户态逻辑死循环但不主动让出 CPU 的卡死top里状态是 RCPU 却很低或很高。用gdb -p PID挂上去后thread apply all bt看每个线程的栈。注意动作要快挂上去进程会暂停查询完立即 detach。如果脚本化了这个操作一个小时内完成几趟也没问题。还有一个隐蔽场景进程卡在uninterruptible sleep里但磁盘看起来正常。这时用ps -o wchanstat看具体等待的内核符号。有一种典型情况是进程在访问 NFS 时因为网络分区导致 IO 永远阻塞。此时不能随便重启可能把文件系统的脏页问题放大正确做法是解除挂载或修复网络再观察进程是否恢复。7.3 内存持续飘升是泄漏还是缓存有一类问题最难缠进程运行时间越长占用内存越大直到 OOM。要判断“内存泄漏”和“缓存增长”得学会区分 RSS 和 page cache。ps aux里的 RSS 是进程当前持有的物理内存包括映射的共享库、堆栈、匿名页。如果一个进程的 RSS 持续线性增长且下降不回来大概率是堆上对象只增不减比如没有释放的引用、积压队列。而页缓存是内核缓存的磁盘数据进程退出后可以被其他进程复用不太算泄漏。排查方法连续观测pidstat -r 1 10或者脚本读取/proc/PID/smaps里面细分了堆、栈、映射、共享内存。如果看到堆段一直在涨就抓 heap dump。Java 用jmap -dump:live,formatb,fileheap.hprof PID分析器打开后看保留大小排名靠前的对象。C/C 用 Valgrind 或者 ASAN但生产环境基本不开只能在测试环境复现。线上最用得上的反而是gdb里的info proc和cat /proc/PID/maps看看哪个映射区域特别巨大。还有一种“伪泄漏”进程内存上涨是因为它大量使用 mmap 映射了文件或者缓存了线程栈、连接缓冲区。这时候 RSS 高但并不会无限制增长通常会在一个高水位稳定。判断方法是跟踪得多一点时间——真正的泄漏是持续上升而缓冲区增长是到峰值后平坦。从经验看很多疑难 OOM 其实是共享内存或者临时目录文件没有清理造成的。ipcs -m查看共享内存段用lsof L1查看已删除但被进程占用的文件。这种被删文件特别阴它们的 inode 被进程持有磁盘空间已经释放不回来了而且内存映射一直占着进程重启前无从回收。7.4 僵尸进程堆积快速止血与根治如果你的系统出现了成百上千的僵尸进程分分钟可能导致 PID 耗尽。止血和根治要同步进行。止血杀掉僵尸进程的父进程让 init/systemd 接管并回收。注意不要盲目pkill因为父进程可能是某个服务的主进程杀掉它会把正常业务一起带没。要先确认父进程是谁用什么工具ps -o ppid -p 僵尸PID找到 PPID 之后ps -fp PPID看父进程是什么。如果父进程是一个短生命周期脚本等它退出僵尸就会被回收如果父进程是常驻服务基本确定是它的代码问题。根治从代码层面父进程要signal(SIGCHLD, SIG_IGN)或者显式调用waitpid循环回收。忽略 SIGCHLD 的另一种含义是告诉内核“我自己不管子进程退出状态你直接回收”这样子进程退出时不会变成僵尸。但很多有特殊需求的进程比如需要知道子进程退出码就不能简单忽略得用非阻塞waitpid(-1, status, WNOHANG)挂在一个循环里。实时处理也可以写个定时器每分钟用 find 扫描一次僵尸进程记录数量趋势。如果数量稳定不再涨说明只是历史残留如果持续增长说明父进程有活没干完等到它下一次wait才会清理。这类问题的排障转折点通常是检查父进程有没有被意外的信号打断导致 wait 逻辑没有执行。8. 真实项目视角一次完整的进程故障复盘我讲一个虚构但非常典型的案例帮你把上面的工具串成一条时间线。某次大促模拟环境一台服务器报了负载高、接口 P99 延迟飙升。登录后的第一件事top -c看到 CPU 满CPU 的 us 比例很高不是 sys同时有一个 PID 叫pay-worker的进程占了两倍核数因为各线程总和。top -H锁定到线程 LWP 3321 占 98%。我们没有直接 kill而是先做了三件事strace -f -p 3321 -tt -T抓十秒发现此线程大量调用read()和write()到同一个 socket fd。说明线程在密集地做网络 IO。ss -anp | grep 3321查这个线程监听的连接发现它连接到一个 Redis 节点连接数非常多。redis-cli --latency看了一下那个节点的延迟高得离谱说明 Redis 有问题。再往深挖执行cat /proc/3321/stack看到线程阻塞在tcp_recvmsg等待包到达。问题脉络已经清晰Redis 节点因为网络抖动或 CPU 竞争导致请求响应突然变慢pay-worker的很多线程都在同步等待 Redis 响应越积越多把整台机器 CPU 和线程池全部拖满。如果把责任归给“某个进程 CPU 打满”就错了它的 CPU 高只是阻塞前的排队消耗。后续处理方式是修复 Redis 节点给支付服务的连接池加超时和熔断。这个案例说明看进程永远要看它背后的 IO 依赖。strace、ss、/proc/pid/stack三件套组合起来比单纯盯着 top 高效得多。另一个常见案例是磁盘满导致进程全部 D 状态。df -h看到/var满但进程状态全是 D说明不是 SQL是文件系统被吞了。这时候任何对写日志、写锁文件、写临时文件的进程都会卡在write或fsync上。注意磁盘满和 IO 性能差是两个原因前者会立刻触发大量 D后者是缓慢积压。可区分的方法是观察/proc/PID/io的写入平均速率磁盘满时等待不增长IO 慢时还在小步增长。最后提一句做进程排障要有“现场保护”意识。能开 core 的时候开 core能留日志的留日志能记录 timestamp 的尽量记录。因为很多疑难问题不是当场能解开的等你想回头复盘的时候现场已经没了。9. 进程管理的最佳实践一些值得长期坚持的习惯9.1 给进程做“标识管理”别在监控里猜创建长期运行的服务时如果有多个同类进程强烈建议对命令行做区分标记。比如java -Xmx2g -Dservice.nameorder-order和java -Xmx2g -Dservice.namepay-pay这样ps -ef能一眼区分。很多公司用 supervisor/systemd 管理进程也都要求在启动参数里带上可读标识。否则你看到的是一排相同的进程名 PID 只能靠猜排障效率极低。systemd 环境下每个服务有明确的ExecStart和Restart策略。要学会systemctl status查看进程状态、systemctl list-units --typeservice --statefailed查看失败服务。systemd 还可以限制服务内存在 unit 文件里配置MemoryHigh、MemoryMax、CPUQuota配合TasksMax限制进程线程数比在没有 cgroup 的裸环境里靠人工强太多了。9.2 用监控把进程信息前置而不是全靠登机器进程排查做得好不好一半取决于你提前采集了什么。建议每个节点采集以下进程级指标按进程聚合的 CPU、内存、线程数、打开文件数、TCP 连接数、进程重启次数。利用node_exporter或telegraf等采集器配合 prometheus 这类时序查询聚合一旦出现指标奇怪变化就能回溯到“哪个进程在什么时候开始异常”。这比出事后登机器再找原始现场高效太多。进程级监控还要补一个维度文件描述符。每台机器存在系统级ulimit -n也有进程级 RLIMIT_NOFILE。ss -s查看当前 socket 用量配合lsof | wc -l观察句柄总量。句柄泄漏是很多线上服务的老年病如果不提前监控等到too many open files爆发往往已经是批量故障。我见过一个服务稳定运行一个季度后在某天早上全体失败就是因为打开的网络连接没有关闭文件描述符每天增长几百个最终触顶。9.3 给“杀掉”和“重启”设红线进程管理中最容易犯的错误就是乱杀。我的经验是碰到一个进程有问题先回答四个问题——这个进程是不是有状态杀掉会不会影响外部依赖有没有健康检查能自动拉起重启瞬时会不会造成流量高峰回答完了再做。对需要平滑重启的系统一定要留 ACM优雅退出时间收到 SIGTERM 后先把当前请求做完了再把新流量切走最后退出。如果批量重启一批有状态的服务要阶梯式重启不要全部同时重启否则依赖它们的下游瞬间全部超时。线上故障时人的应激反应往往是快速重启以救火但重启一时爽之后可能要背更复杂的锅。最后分享一点个人体会做 Linux 进程相关的工作久了我发现最难的不是某个命令记不住而是“遇到问题时脑子里能不能快速画出进程全貌图”从 PID 到父子关系、从状态到栈、从 CPU 到 IO 依赖、从 cgroup 到整个宿主机的资源边界。每次排障都是一次把知识加工成直觉的训练。希望这篇文章能帮你把散落的知识串成一条线。真遇到棘手问题建议先把现场信息多留几份再动手很多时候你的第一步操作决定了你索引问题的起点。