“你在服务器上敲下ps ax看到一大屏进程列表的时候心里到底在想什么”这是我每次带新人时必问的问题。绝大多数人的回答是“哦就是查看所有进程。”然后就没有然后了。ps ax确实是最经典的“查看所有进程”的命令组合之一但它能告诉你的远不止“哪个进程还活着”这么简单。尤其是 STAT 那一列里藏着的S、D、Z、T直接对应着 Linux 内核调度器眼中这个进程的状态。而最近社区里开始流行“ax调度”这个说法说白了就是大家发现与其玄学调优不如先用ps ax把进程状态和调度行为对齐再决定该干什么。这篇文章我想把ps ax这条命令彻底讲透并且把它和进程调度联系起来。适合刚接触 Linux 的后端开发、运维、SRE也适合那些写了多年业务代码、但很少仔细看系统进程状态的工程师。我会从命令参数、输出字段、状态含义一直讲到实际排查问题时的组合拳最后再分享一些踩坑心得。1. 别小看这条命令ps ax到底在看什么1.1 从“ax”两个字母说起ps ax里的a和x是两个非常有历史感的参数。如果你去看 Linux 的 ps 手册页会看到这样一段描述a表示列出所有带有终端tty的进程包括其他用户的进程x表示列出所有不带控制终端的进程。这两个参数合在一起基本就把系统上所有“活着的”进程都覆盖了。为什么这个组合这么经典因为很多关键的后台守护进程、系统服务、worker 进程恰恰是“没有控制终端”的。如果你只用默认的ps你只能看到当前终端下的进程那些真正决定系统性能的 daemon 进程根本不会出现在列表里。而加上x之后你才能像掀开地板一样看到系统底层真正在跑的东西。很多人也会用ps aux这两个到底有什么区别简单说ps ax是标准 POSIX 风格的语法ps aux是 BSD 风格。区别在于aux里的u会让输出多一列USER显示进程属于哪个用户。而ps ax默认不带 USER 列。它俩在“显示全部进程”这一点上范围基本一致只是字段布局不同。我个人的习惯是排查问题时用ps aux因为能看到是哪个用户起的进程定位问题更快。但如果是写脚本做监控、抓取进程快照我更倾向于ps ax -o pid,stat,comm这种字段明确的写法而不是依赖默认输出格式。1.2 看懂输出的每一列执行ps ax之后你看到的默认输出包含四列PID进程号每个进程的唯一标识。TTY进程关联的控制终端。?表示这个进程没有控制终端这通常是后台服务。STAT进程状态这一列是调度的核心信息后面我会详细拆。TIME进程累计占用的 CPU 时间。注意这不是“运行了多久”而是“消耗了多少 CPU 时间”。COMMAND命令名也就是这个进程是怎么启动的。只看默认输出你只能知道“有这个进程存在”。但如果加上-o参数你可以自定义输出字段就能看到更多有价值的信息。比如ps ax -o pid,ppid,user,stat,%cpu,%mem,nice,lstart,cmd这段命令会输出父进程 IDPPID、用户、状态、CPU 占用、内存占用、nice 值、启动时间以及完整命令。其中的 nice 值就是进程调度的“优先级数字”。配合lstart看启动时间很多“这个进程是什么时候开始捣乱的”问题就能一眼定位。很多人写脚本时喜欢用ps -ef它的输出风格和ps ax不一样但它更接近“完整命令行”的展示方式。如果你需要在脚本里精确抓字段建议用ps ax -o自定义输出这样不用依赖空格分割的位置解析起来更稳。1.3 为什么“ax调度”这个说法会流行起来最近“ax调度”这个词在技术社区里被频繁提起其实不是ps ax命令本身获得了什么新功能而是大家把它和“调度”这个概念绑定在了一起。核心逻辑是在线上环境排查问题时先用ps ax拿全局进程快照再通过 STAT 字段判断每个进程到底处于什么调度状态——是正在运行还是睡眠等待还是卡在不可中断的 IO 上。这种“先看状态、再谈调度”的思路比上来就top看 CPU 更接地气。因为top显示的是一瞬间的负载而ps ax能列出所有进程的实时状态尤其是 D 状态和 Z 状态这类“问题信号”在top里一闪而过但在ps ax的输出里能稳定捕捉到。另外一个原因是很多人在排查“为什么系统负载这么高CPU 却不高”这类诡异问题时发现答案往往不在 CPU 上而在进程的调度状态上——大量进程卡在 D 状态不可中断睡眠等 IO或者大量僵尸进程堆积这些都会导致 load average 飙升但 CPU 使用率看起来很正常。这时候ps ax就是你最直接的排查起点。2. 进程状态解码从STAT字段看透进程在干嘛2.1 状态字母全集R/S/D/T/ZSTAT 字段是ps ax输出里信息密度最高的一列。初学者看到一排字母一脸懵老手看到 STAT基本就能猜出进程在干什么、有没有问题。先看最常见的几个R正在运行或者处于可运行队列中等待被调度。它是“活蹦乱跳”的状态通常是 CPU 密集型进程。S可中断睡眠。进程在等待某个事件完成比如等待网络数据、等待锁、等待磁盘 IO 完成。这是最普遍的状态绝大多数服务进程长期处于 S。D不可中断睡眠。这个状态很特殊通常是进程在内核态等待 IO 完成比如磁盘同步、NFS 等待等。这个状态吃信号、杀不掉只能等 IO 恢复。T已停止。进程被暂停通常是因为收到了 SIGSTOP 或 SIGTSTP。用kill -CONT可以继续。Z僵尸进程。进程已经退出但父进程还没有调用 wait() 回收它的退出状态。僵尸进程不占用 CPU但如果大量堆积会占满进程表。有人会把R和S搞混以为只有 R 的进程才消耗 CPU。实际上一个进程处于 S 状态时也可能瞬间切到 R 状态执行一小段时间然后再回到 S。STAT 只是一个“快照”不是“历史统计”。我见过最典型的误判是看到top显示某个进程 CPU 100%但ps ax显示它是 S 状态于是怀疑系统不准。这其实不矛盾——S 状态的进程在等待事件但事件可能是一个高频率的定时器回调它每次醒来就跑满一个时间片累计 CPU 时间蹭蹭涨但快照时刻恰好是在睡眠中。2.2 状态里的符号并非装饰STAT 字段除了字母还会出现一些附加符号比如s、l、、、N。这些符号不是装饰每一个都有明确的调度含义。s表示这个进程是会话领导者session leader。简单说它可能是你那个登录 shell也可能是一个服务的领头进程。l表示这个进程是多线程的。表示这个进程位于前台进程组也就是说它正在当前终端的前台运行你能直接和它交互。高优先级进程通常意味着它的 nice 值为负数。N低优先级进程nice 值为正数也就是“让着别人跑”的进程。L内存页面被锁定lock一般少见涉及实时进程或某些特殊 IO。组合状态也很常见比如Ssl就是睡眠状态、会话领导者、多线程。再比如R是正在运行、高优先级。这些都是判断进程行为的重要依据。有一个很典型的排查场景你发现某个 Java 进程状态是Tl也就是“停止 多线程”。如果它不是被人为 SIGSTOP 了那大概率是被人用 gdb 或者 jstack 挂住调试了。在线上环境碰到这种状态要么是有人在调试要么是代码里主动调用了暂停逻辑。2.3 状态和调度的关系理解进程状态不能只看状态本身要把它和调度器联系起来。Linux 的调度器CFS完全公平调度器只关心 R 状态的任务——它会把 CPU 时间按权重分配给所有R和S状态中“刚刚醒来”的任务。关键点在于调度器的“可运行队列”里不止有 R 状态进程还包括那些临时处于 S 状态但即将醒来的进程。它们通过 wait queue 机制在等待事件完成后会被重新插入运行队列。这个过程在ps ax里看不出全貌但 STAT 字段的状态切换实际上是调度器运作的外在表现。所以当你看到大量进程处于D状态时真正的信息是这些进程在内核态被 IO 阻塞了调度器根本无法把它们纳入可运行队列更谈不上什么公平调度。这时候系统负载高不是因为 CPU 不够而是因为 IO 资源到了瓶颈。这也是“ax调度”这个概念的精髓用ps ax看到的进程状态去反推调度器遇到了什么问题。而不是一上来就调 nice 值、换调度算法——那是先开药方、后看病的错误做法。3. 调度视角谁在优先跑谁在排队等3.1 Linux默认调度器CFS与nice值Linux 从 2.6 版本开始默认的调度器就是 CFSCompletely Fair Scheduler完全公平调度器。CFS 的思路并不是“时间片轮转”而是维护一个虚拟运行时间 vruntime。每个可运行进程的 vruntime 随着它占用 CPU 的时间不断增长调度器每次都选 vruntime 最小的进程去运行——也就是说谁跑得少谁就优先跑。nice 值在这个机制里扮演的是“权重调节器”的角色。nice 的取值范围是 -20 到 19默认是 0。nice 值越低进程的权重越高被调度到的机会越多nice 值越高越“谦让”。它叫 nice意思是“对别人友好的程度”nice 值越高对这个进程自己越不友好。用生活化的类比来理解CFS 就像一个公平食堂所有排队的人按“谁先来的先打饭”排队。而 nice 值是食堂给你的“优先卡”——nice 值低的人相当于有钻石会员卡可以插队nice 值高的人相当于“你们先吃我再等会儿”的谦让者。但注意nice 值只影响“相对优先级”不影响“绝对优先级”。在 CFS 的架构里也没有真正的“绝对优先级”概念——只有实时调度器SCHED_FIFO / SCHED_RR才有绝对优先级。3.2 用ps -l、nice、renice实战调整查看进程的 nice 值最直接的方式是ps ax -o pid,comm,nice,stat输出里会有一列NI显示该进程的 nice 值。如果是负数说明这个进程正在以高于默认的优先级运行如果是正数说明它以低于默认的优先级运行。启动进程时设置 nice 值有几种做法nice -n -5 ./my_server这个命令用 nice 值 -5 启动my_server。注意普通用户只能把 nice 值往“高”调比如从 0 调到 10只有 root 才能往“低”调从 0 调到 -10。这是为了防止普通用户把系统资源全部抢走。调整一个已经运行的进程的 nice 值用 renicerenice -n 5 -p 12345把 PID 12345 的 nice 值设为 5。这个操作很实用比如一个后台数据任务突然开始消耗大量 CPU但它不是核心服务你可以临时把它的 nice 值调高让它“让路”。还有一个容易忽略的点ps -l的输出里除了 NI 列还有PRI列。PRI是调度器内部计算出来的“实际优先级”它不是直接设置的而是根据 nice 值和内核其他因素计算出来的。在 CFS 下ps显示的 PRI 是 80 nice 值。你可以在命令里看到当 nice 为 0 时PRI 显示为 80nice 为 -5 时PRI 显示为 75。这个对应关系能帮你快速理解系统内部状态。3.3 实时调度与普通进程的区别CFS 负责的是普通进程SCHED_NORMAL / SCHED_OTHER而 Linux 还有两种实时调度策略SCHED_FIFO 和 SCHED_RR。实时进程的优先级范围是 1 到 99数值越高优先级越高而且它们的优先级永远高于所有普通进程。怎么判断一个进程是不是实时调度的可以用chrt命令chrt -p 12345输出会显示policy: SCHED_NORMAL或policy: SCHED_FIFO等。默认情况下绝大多数进程都是 SCHED_NORMAL只有少数特殊需求比如音频服务、部分工业控制软件才会设置成实时策略。实时优先级在ps输出里并不会直接显示但可以从 STAT 字段的符号里得到线索。如果进程是SCHED_FIFO运行它的状态通常带有高优先级标志。查看实时优先级本身更准确的方式是chrt或者直接读/proc/pid/sched。特别提醒不要轻易把业务进程改成实时调度。如果有一个实时 SCHED_FIFO 进程进入死循环它会把整个 CPU 占死其他所有普通进程都得不到调度系统直接“假死”。这在生产环境是一场灾难。我见过有人为了降低自己服务的延迟把进程改成实时调度结果某个线程异常后整台机器连 ssh 都连不上去只能强制重启。4. 实战排查用ps ax诊断线上问题4.1 找出CPU狂飙的元凶线上最常见的告警之一就是“某个节点 CPU 使用率超过 90%”。很多人的第一反应是登录机器执行top然后看哪个进程 CPU 高。但我更推荐先用ps ax做一次“冷启动定位”ps ax -o pid,ppid,user,stat,%cpu,%mem,nice,comm --sort-%cpu | head -20这条命令按 CPU 占用从高到低排序列出前 20 个进程。它比top更适合脚本化因为输出是干净的文本而且--sort可以精确控制排序字段。拿到高 CPU 的进程 ID 后如果发现是一个 Java/Python/Node 服务下一步通常是看它的线程级行为top -Hp PID或者ps -T -p PIDps -T能列出这个进程的所有线程并显示每个线程的 CPU 时间。Java 应用可以用jstack抓线程栈配合 PID 十六进制转换成线程 ID定位到具体代码行。Python 可以用py-spy dump不需要停服务就能抓线程栈。Node 可以用kill -SIGUSR1抓诊断报告。我经常遇到一种情况ps ax --sort-%cpu看到的最高的进程 CPU 只有 10%但整个机器的 CPU 却 100%。这说明瓶颈不是单个进程而是大量进程累计消耗——很可能是 fork 了无数短命子进程或者内核线程异常。这时候要往下看 load average 和进程数量ps ax | wc -l能快速数一下进程总数量如果数量异常膨胀比如上万基本可以断定是 fork 炸弹或者回收逻辑出了 bug。4.2 D状态进程与不可中断等待D 状态不可中断睡眠是最容易让人误判的进程状态。因为它看起来和 S 很像都是“睡眠”但 D 状态意味着进程正在内核态做 IO 操作而且这个 IO 不能被信号中断。你在ps ax里发现大量进程处于 D 状态通常伴随的症状是top的 load average 很高但 CPU 使用率并不高waiowait占比很大。这时候排查的方向不应该在 CPU而在存储和文件系统。排查步骤我一般这么走top -n1 | head -3先看系统的 load average 和 wa 值。如果 wa 超过 20%说明 IO 已经是主要瓶颈。接着用iostat -x 1看磁盘的%util、await、svctm判断是哪块盘在拖后腿。如果系统里用了 NFS还要额外检查网络文件系统。我记得有次排查一个告警A 服务器的进程一直 D 在nfs操作上但本机磁盘 IO 很正常。后来一查是挂载的 NFS 远端存储挂了所有访问远端文件的进程全部卡死。检测手段很简单cat /proc/pid/status看State: D (disk sleep)再用cat /proc/pid/stack看内核栈如果栈里出现nfs相关的函数基本就是 NFS 的问题。D 状态最麻烦的是它“杀不掉”。你kill -9一个 D 状态进程它不会消失因为信号根本无法递达到它。唯一正确的处理是恢复底层 IO或者等 IO 超时返回。实在不行只能重启机器——但要注意重启可能有数据一致性风险。4.3 僵尸进程的处理僵尸进程Z 状态是每个运维都会碰到的东西。它的成因很简单子进程退出时会给父进程发送 SIGCHLD 信号父进程需要调用 wait() 或 waitpid() 来读取子进程的退出状态。如果父进程没有正确回收子进程就留在进程表里变成 Z 状态。在ps ax输出中看到 Z 状态进程你会觉得奇怪它的 COMMAND 显示成[defunct]PID 还占着但用kill -9怎么杀都杀不掉。因为僵尸进程已经是“死掉”的了它不接收任何信号也不需要 CPU纯粹是一个残留记录。遇到僵尸进程正确的处理思路是“顺着 PPID 找父亲”ps ax -o pid,ppid,stat,comm | grep -w defunct假设你发现僵尸进程 PID 是 10001PPID 是 20001接下来去处理父进程ps -p 20001 -o comm如果父进程还活着你可以用kill -CHLD 20001主动给父进程发 SIGCHLD 信号提示它去回收子进程。但更稳妥的做法是直接让父进程处理掉——如果是业务进程可能重启它如果是系统服务可能需要 systemd 的 Restart 机制。有一种僵尸进程特别隐蔽父进程自己变成了僵尸那它的所有子进程都会被 init/systemd 接管。如果 systemd 没有正确回收这些子进程的退出会造成一堆僵尸堆积。不过现代 systemd 对这类情况处理得比较好只要你使用systemctl管理服务这类问题会少很多。4.4 结合top/jstack做纵深排查ps ax只能看到“进程级”的信息问题定位到单进程后往往还要深入到线程级和代码级。这时候的黄金组合是top -Hpjstack。流程是这样的top -Hp 12345在 top 的线程模式下你会看到一个 CPU 占用极高的线程记下它的 TID。然后把 TID 转成十六进制printf %x\n 1234得到十六进制值比如4d2。接着用jstack抓线程栈jstack 12345 /tmp/jstack.log在日志里搜索nid0x4d2就能定位到这个线程正在执行哪段代码。这是排查 Java CPU 问题的最经典路径。如果问题不是 CPU而是锁竞争你会在线程栈中看到大量park、waiting on monitor相关的字样。这时候重点抓“Blocked 状态”的线程分析锁的持有者。ps ax -L也能从进程视角看线程它会把每个线程作为一行输出PID 变成主线程 IDSPID 是线程 ID。在脚本化排查场景里ps -L -p PID比top -Hp更好用因为输出是稳定文本可以用于自动化采集。4.5 内存视角进程占用的隐性排查严格来说ps ax的内存列%MEM、RSS只是粗略的内存占用指标但由于很多人习惯只看它所以我在排查思路里加一段。ps ax -o pid,rss,vsz,comm --sort-rss | head -10能快速列出物理内存占用最高的进程。不过要注意RSS是“驻留内存大小”它可能高估实际唯一占用——因为有共享内存、共享库的存在两个进程可能统计了同一个内存页。更精确的指标是PSSProportional Set Size可以用smem或者cat /proc/pid/smaps_rollup查看。排查内存问题我通常配合/proc/pid/status里的VmRSS、VmSwap来看。进程如果大量使用 swapps ax的 RSS 可能不高但系统整体内存压力已经很大。这时候不能只看进程内存还得结合free -h的内存分布来判断。5. 向运维脚本进阶用ps ax做自动化监控快照5.1 快速打造一个进程快照脚本ps ax不只是给人看的它在自动化场景里一样好用。很多监控脚本的核心采集逻辑其实就是一条ps ax -o自定义输出命令。我分享一下我自己的采集模板。如果是每分钟跑一次的巡检脚本我会这样获取核心指标ps ax -o pid,ppid,user,stat,nice,%cpu,%mem,etime,comm --sort-%cpu | head -30再加上带时间戳的标题直接写入日志文件。这样每次巡检留下一个快照出问题时翻对应时间点的快照能快速对比前后的状态变化。如果要监控某个特定服务是否存活不需要 grep 全套输出直接按进程名定位ps ax -o pid,stat,comm | grep -w my_service如果 grep 没有输出说明进程不在或者它是一个内核线程内核线程在 ps 输出中用中括号括起来比如[kworker]。5.2 监控脚本里的3个坑第一个坑grep -v grep。很多人写脚本时直接ps aux | grep xxx但 grep 命令本身也会出现在输出里造成“自己匹配自己”的假象。最好用pgrep -f xxx或者管道后grep -v掉 grep。第二个坑进程名被截断。默认的ps ax输出中 COMMAND 列可能会被截断尤其是命令行参数很长的时候。如果脚本要拿命令行信息作为匹配条件建议用-o args而不是-o comm它会输出完整的命令行参数。第三个坑PID 被复用。短命进程频繁启动退出可能导致监控脚本抓到的 PID 已经不再是原来的进程而是一个新进程恰好复用了旧 PID。避免这个问题的办法是不只记录 PID同时记录进程启动时间lstart或进程名多个字段联合判断。5.3 工具组合Procps-ng 家族的实用搭档ps命令属于 procps-ng 这个工具包同家族里还有top、kill、pgrep、pkill、uptime、free、watch等命令。它们在排查时经常配合使用。比如pgrep可以按名字找 PIDpkill可以按名字杀进程free看内存分布watch -n 1 ps ax -o pid,stat,comm --sort-%cpu | head -20可以每秒刷新进程快照相当于简陋版的 top。在 SSH 窗口里跑watch比刷新 top 更有针对性因为你可以把看板限定在关心的进程范围内。6. 经验心得与常见问题速查6.1 排查顺序建议根据我个人的经验建议遇到“系统负载异常”时不要直接去看top而是执行一条固定顺序的组合命令who -b先看系统上次启动时间排除重启后的瞬时噪音。然后uptime看 load average 三个数值如果 1 分钟 5 分钟 15 分钟说明负载在快速上涨如果反着来说明系统正在恢复。接下来才轮到ps axps ax -o pid,ppid,user,stat,comm --sort-%cpu | head -20先看有没有异常的进程状态、异常的 CPU 占用。然后结合free -h看内存df -h看磁盘空间iostat -x 1看 IO。这套顺序能帮你快速区分问题维度是 CPU、内存、磁盘还是进程状态异常。6.2 常见问题速查表现象关键检查命令可能原因处理建议单个进程CPU满ps ax -o pid,comm,%cpu --sort-%cpu | head业务死循环、锁竞争、JDK版本bug抓线程栈定位代码必要时重启并升级整体CPU低但负载高ps ax | wc -l、iostat -x 1大量D状态进程在等IO检查磁盘、NFS、存储设备状态进程无法杀死cat /proc/pid/status进程处于D状态恢复底层IO重启设备不要盲目kill僵尸进程堆积ps ax -o stat,ppid,comm | grep -w Z父进程未回收子进程定位PPID处理父进程进程被暂停ps ax -o stat,comm看到T收到SIGSTOPkill -CONT pid某个服务突然变慢ps ax -o pid,etime,nice,stat,comm进程长期运行但状态异常或优先级被降低检查配套日志结合系统调用分析6.3 最后再分享一个小技巧ps ax有一个被很多人忽略的选项-k或者--sort可以实现多级排序。比如先按 CPU 降序再按内存降序ps ax -o pid,comm,%cpu,%mem --sort-%cpu,-%mem | head -20这在排查“CPU 和内存哪个更有问题”的时候特别有用。另外如果你想把进程树看得很清楚可以用ps axf它的输出会带上 ASCII 树状结构能直接展示父子进程关系比单纯ps ax更直观。排查僵尸进程时ps axf能让你一眼找到那个“没回收孩子”的父进程。我在实际运维中ps ax的地位相当于“系统进程的显微镜”。它不能直接告诉你答案但它能以一种极其稳定的、可脚本化的方式把系统进程的状态陈列在你面前。配合对调度机制的理解你就能在乱麻一样的系统进程里快速找到那根关键的线头。如果每次排查问题你都能从进程状态出发去推理系统行为而不是靠重启服务器解决问题那你离一个真正的系统问题排查专家就不远了。