庖丁解牛Linux进程排查：ps aux按CPU排序的底层逻辑与实战-北京尧图网络

1. 这条命令为什么值得拆成八块看最早接触Linux系统排查的时候前辈丢给我一句看谁吃CPU跑这条就是ps aux --sort-%cpu | head。当时只知道抄着用后来自己带人、写脚本、调性能回头再看这条命令才发现它几乎把Linux进程查看的底层逻辑都串了一遍。把它当庖丁解牛来解不是因为词穷而是因为它确实够格——每个单词拎出来背后都是一套机制而且这套机制搞明白了很多排查问题的手段自然就通了。先说这条命令在干什么列出当前系统中按CPU占用率从高到低排序的进程列表然后只取前10行左右默认head是10行。就这么点功能但它的适用场景非常广——服务器CPU飙到100%的时候你想知道是哪个进程在搞事跑着一堆Java应用的主机上你想看一眼谁在狂吃CPU而不是吃内存甚至写CI脚本时想动态抓一个进程名带xxx且CPU超过阈值的PID它都是最顺手的起手式。我见过不少新人刚开始不拆解它直接背命令遇到两个问题就卡壳一是ps aux里的aux和ps -ef的-ef到底什么区别二是--sort-%cpu这个-号和%号的真实含义。这篇文章就是把这条命令从管道符两侧逐个拆开再组装回去顺带补上一些你用得上但文档里不常写明白的细节。适合谁来读刚接触Linux一两个月、还在跟ps参数搏斗的人已经会用top但想把命令行方式玩得更透的人以及写监控脚本时想知道为什么这条命令偶尔会漏掉进程的人。我尽量把原理讲透但不堆术语读完你不仅能默写这条命令还能随手变出它的各种变体。2. 拆开ps aux每个字母都不是白给的2.1 从进程结构说起ps到底在读取什么ps全称是 process status它的本质是从内核的进程表process table里读取进程描述信息。Linux 内核用一个叫 task_struct 的结构体描述每个进程里面记录着 PID进程号、PPID父进程号、状态、优先级、启动时间、累计CPU时间、内存映射、打开的文件描述符等海量信息。ps这个用户态程序本身不维护任何进程数据它只是照镜子把内核里登记的信息按你指定的格式和过滤条件呈现出来。aux不是辅助的意思它是三个参数的合写a、u、x。合写是Unix系命令的老传统ps aux是老式BSD风格选项的经典组合在Linux的procps-ng实现里被兼容并保留了下来。2.2a、u、x各自管的范围a的含义是显示所有终端tty下的进程包括其他用户的进程。很多人误以为a就是all所有但严格说它不是。不带a时ps默认只看当前终端关联的进程加上a之后范围扩展到所有终端还带上了别人在别的终端里跑的进程。u是面向用户的详细格式它决定的是输出列不是筛选范围。u会在输出里加入 USER、PID、%CPU、%MEM、VSZ、RSS、TTY、STAT、START、TIME、COMMAND 这些列。其中 %CPU 和 %MEM 是我们在排查时最盯着的两列关于它们的计算逻辑我在第3节单独展开。x则是包括没有控制终端的进程。什么叫没有控制终端最常见的例子就是守护进程daemon它们由 init 或 systemd 拉起不与任何 shell 终端绑定普通用户交互时根本看不见。还有我们常用的nohup 命令丢到后台跑的进程如果进程没有主动脱离终端它仍然挂在某个tty下但如果它被 setsid 之类的方式脱离会话就会变成无终端状态。x就是把这些幕后进程也拉出来亮相的开关。把三者合起来看a扩展人的范围所有用户x扩展终端的范围连终端都没有的也看u提供易读的详细列。所以ps aux翻译成人话就是把系统里几乎所有用户态的进程都列出来用带CPU和内存占比的详细格式展示。有一个小差异很多人没注意ps aux和ps -aux就差一个横杠但行为不完全一样。在GNU/ procps 实现里ps aux被解释为BSD选项集合而ps -aux会被解析成-a -u -x这种SysV风格其中-u在这里变成了按指定用户过滤的意思比如ps -u root是看root的进程。所以如果哪天你敲了ps -aux却输出了一个奇怪的user list那不是系统坏了是参数被解释成了列出所有用户-a的进程并显示用户信息-u且包括无终端进程-x——能跑但某些procps版本下-aux的行为和aux并不完全一致。日常使用写ps aux别加那个横杠。2.3 STAT列和TIME列排序之外的隐藏情报用ps aux输出后你会发现除了%CPU、%MEM这两列外STAT和TIME也值得好好看因为它们直接影响你后续的判断。STAT表示进程状态常见组合比如Rrunning正在运行或可运行在就绪队列里Ssleeping可中断的睡眠最常见等事件/等IOD不可中断睡眠通常在等磁盘IO如果D状态进程大量堆积说明IO系统可能扛不住了Z僵尸进程父进程没回收占着PID但已经是尸体T停止通常是被CtrlZ或SIGSTOP挂起后面还会跟着高优先级、N低优先级、l多线程、s会话首进程、前台进程组等修饰字母如果%CPU很高但STAT是 S而不是 R说明这个进程在等CPU还是在等IO中间打转需要结合pidstat、perf进一步确认。只看CPU数字就下结论是新手排查时最容易犯的错。TIME列是进程累计消耗的CPU时间用户态内核态注意它不是进程跑了多久而是这个进程这辈子在CPU上跑累计算了多少秒。举个例子一个进程STAT显示R%CPU显示90%TIME显示3分20秒。这意味着它现在的90%是高占用累计已经烧了200秒CPU时间。如果另一个进程 %CPU 只有5%但TIME已经2小时说明它是个长命低频进程或者曾经疯狂吃CPU后来休眠了。这两列配合看能帮你分辨当下谁在搞事和谁曾经搞过事。3.--sort-%cpu排序的坑和CPU占比的真相3.1 GNU/BSD两种排序语法的区别--sort是GNU风格的排序选项等号后面跟排序键。这里必须注意procps 的 ps 同时兼容BSD风格和GNU风格选项而排序键的写法在不同风格下有差异。在BSD风格里排序是通过关键字前加-表示降序、加表示升序完成的比如ps aux --sort-%cpu的BSD等价写法是ps aux k-%cpu这里的k是老式排序选项。不过更常见的GNU写法就是--sort两者并存但推荐用--sort因为语义更明确而且能跟脚本里的其他GNU风格选项比如-o保持一致。键名%cpu里的百分号不是随便加的。在procps里排序键可以直接用输出列名列名可以带百分号表示CPU占比比如%cpu、%mem也可以不带百分号写成pcpu、pmem效果一样。所以--sort-%cpu和--sort-pcpu是等价的。很多人第一次看到--sort-%cpu以为%是某种特殊转义其实它只是列名语法。-号放在键名前面代表 reverse降序。CPU占用从高到低就加上这个减号。如果是--sort%cpu不带减号就是从低到高升序排列。合并多个键用逗号比如--sort-%cpu,-%mem表示CPU降序、内存降序主排序键相同的时候才轮到第二键。3.2%CPU究竟是瞬时还是平均——大多数人的误解ps aux显示的%CPU并不是此刻这一瞬间的CPU占用率。它的计算方式是按进程累计CPU时间在采样周期内的增量来估算的。procps 的实现细节是ps自身每秒钟刷新一次进程数据通过读取 /proc/ /stat 里的字段%CPU的值 (该进程两次采样之间消耗的 CPU 时间 jiffies 差) ÷ (两次采样之间的总时间差) 。说白了它更像最近这一小段时间内的平均占用率而不是像top那样按固定刷新周期实时重算。由于ps是拍一张快照然后退出它采样到的是一瞬间的增量所以%CPU的数值有一定波动极端情况下对于瞬间飙高立刻回落的短命进程甚至可能显示为0%——不是进程没吃CPU是它跑太快采样点没抓到。因此如果你要拿ps aux --sort-%cpu的结果当监控报警依据建议加上--sort排序后用head截取前几名没问题但不要追求精确到小数点更稳的方案是连续多拍几次比如间隔1秒采样3次或者直接上top -b -n 2或pidstat 1 5。脚本里要做阈值判断的话ps -eo pid,pcpu,comm --sort-pcpu输出更好解析避免被aux的宽列干扰。3.3%CPU超过100%多核机器的正常现象一个我在答疑时几乎每次都要解释的点ps aux里的%CPU可以超过100%比如显示 200%、800% 等。原因很简单多核处理器下进程/线程可以并行使用多个核心。这个%CPU数值实际上是按单核利用率归一化后的相对值吗不是procps 把它按总CPU时间的占用比例计算但上不封顶——它可以超过100%表示这个进程或其多线程同时占用了多个核心。举例一台4核机器上一个多线程应用把4个核都打满%CPU可能显示 400%。这不是bug是特性。如果你看到%CPU300%而top里总体CPU usage 才 75%说明这台机器总共4个核其中一个进程吃了3个核剩下的活给其他程序留了一个核。判断CPU是否被打满不要看单个进程的%CPU要看整个系统的load average和top里的总CPU使用率。3.4 关于%cpu排序键的兼容性提示在写脚本时如果想把这条命令的结果丢给awk或cut处理我建议用-o自选列而不是直接解析aux的宽表。一条经典组合ps -eo pid,user,pcpu,pmem,comm --sort-pcpu | head -n 20这个写法把输出列收窄第一个是PID最后一个是命令名不会有aux里时间列、终端列导致的行宽错位问题。注意comm只显示命令名被截断到15个字符args显示完整命令行可能带参数、可能很长。脚本抓PID时用comm人眼排查时用args各取所需。4. 管道符|和head一场你死我活的合作4.1 管道到底怎么工作head为什么能砍断输出管道符|的本质是连接两个进程的标准输入和标准输出它创建了一个单向的数据通道左边命令的 stdout 接到右边命令的 stdin。这个通道在内核里是一个环形缓冲区pipe buffer容量有限Linux 上默认通常是 16 页约 64KB具体得看系统配置。ps输出的文本数据通过这个缓冲区流到head的输入。head是一个读够就停的程序它的默认行为是读取前10行然后退出。关键在于退出这一下当head读取到第10行、任务完成它立刻调用 exit所有文件描述符被关闭管道的读端随之关闭。此时左边的ps还在写管道吗如果它写的时候发现管道已经没有读端内核会给它发一个 SIGPIPE 信号它就会收到一个管道的另一端已关闭的提示默认动作是终止进程。于是ps被迫提前结束哪怕它本来打算把几千行都列出来。这在效率上是巨大的优化ps aux如果不加管道需要遍历所有进程并格式化输出几千行加了head之后由于管道缓冲区有容量且head快速退出ps往往只写了少量就被 SIGPIPE 带走省掉了后续大量无意义的格式化与写入。所以你输入这条命令时感受到的秒出结果有一半功劳来自head的截断和 SIGPIPE 的牺牲机制。4.2 为什么head和tail在这里不对称常见问答里有人问为什么排查CPU高的进程要用head而不是tail因为在--sort-%cpu降序排列下CPU占用最高的一定排在最前面你要的就是头几行自然用head。如果哪天你想看CPU占用最低的10个进程就必须把排序改成升序--sort%cpu然后再用head或者保持降序用tail -n 10截取末尾——但tail必须等整个输入流结束才能知道哪些是最后10行所以它做不到head那样的提前中断优化性能上会慢不少。这也是我在优化自己的监控脚本时悟出来的一个点需要最高/前几名就降序head既省资源又清晰需要最低/最后几名也尽量用升序head而不是降序tail就是为了利用 head 提前终止的特性。4.3 head 的-n参数和常见误用head -n 20取前20行这在面试和日常中很常见。但还有一个容易被忽视的重复性问题当内容行数不足、或者你想要的行数恰好跟进程数一样时head的提前终止不会触发 SIGPIPEps正常跑完这也完全没问题。如果说坑最常见的其实是用head截行数但忘了管道里有ps的表头。ps aux的第一行是标题行USER PID %CPU ...所以head -n 11才是标题行真正前10个进程。如果你直接数进程个数然后取前10得到的是9个进程——这个细节在写脚本截取PID时特别容易踩中。一条比较稳的解析写法剥离标题行并抓最耗CPU的前5个PIDps aux --sort-%cpu | awk NR1 {print $2, $3, $11} | head -n 5这里awk的NR1先跳过了标题行再取第2列PID、第3列CPU、第11列COMMAND。但注意第11列可能是带路径的完整命令且如果命令有空格参数$11只会取到第一个词所以实际用得更细的话可以改用-o来定制列。4.4 管道的断是特性不是错误很多人敲ps aux --sort-%cpu | head如果直接看echo $?会得到0或141偶尔还会困惑怎么ps好像没跑完就结束了。这里再补充一下当管道中的某个命令被 SIGPIPE 杀死时整个管道的退出状态由最后一个命令head决定通常head正常退出会返回0。如果你在脚本里有set -o pipefail则会把这个 SIGPIPE 状态传递出来这时你需要知道 141 128 1313是SIGPIPE的信号编号。这在日志里看到141退出码的时候不要慌它大概率只是前面的命令被head提前砍断而已不是程序崩溃。如果不想看到141可以在 ps 后面加|| true或者在管道外层用if !包裹——但一般情况下脚本里合理使用set -o pipefail并接受141是更诚实的做法。5. 实战一条命令在CPU排查现场的使用艺术5.1 一次完整的CPU狂飙排查演示假设你是某台线上服务器的维护者突然收到告警说CPU使用率超过90%。你的第一反应就是敲这条命令ps aux --sort-%cpu | head输出前几行可能是这样的示意USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 12345 350.0 8.2 4200000 300000 ? S 10:02 80:00 /opt/app/bin/java -Xmx4g -jar gateway.jar root 12346 25.0 2.1 1500000 80000 ? S 10:03 5:00 /usr/bin/python3 worker.py ...看到 350% 的时候新手容易愣住但按前面说的多核原理这台机器至少有4核所以 350% 意味着这个Java进程占据了3.5个核。再看TIME列 80分钟是个持续吃CPU的长命进程不是刚启动瞬间抖动。接下来用top -H -p 12345或ps -L -p 12345 -o pid,tid,pcpu,comm查看该进程内部的线程。很多Java应用的问题都出在GC线程或某几个业务线程上ps -L -p 12345 -o pid,tid,pcpu,comm --sort-pcpu | head这一步能看到是哪个线程在烧CPU。比如发现某个名为GC Thread的线程占掉200%基本可以断定是JVM垃圾回收压力大接着可以抓jstat或jmap做堆分析。如果看到的是业务线程名字再jstack抓线程栈定位到代码。这就是从找到进程到定位到线程/代码的完整链路而ps aux --sort-%cpu | head就是这个链路的第一块敲门砖。5.2 高频变体内存版、线程版、用户版同一条思路可以换排序键换出很多花活。按内存占用排序ps aux --sort-%mem | head -n 20这在排查内存泄漏疑云或谁把RAM吃光时非常常用。注意%MEM的含义是进程的RSS占物理内存总量的百分比不是占swap、也不是虚拟内存。如果一个人说内存快满了你敲这条命令大概率能找到那个RSS飙高的进程。只看某个用户的进程并按CPU排序ps -u someuser -o pid,pcpu,pmem,comm --sort-pcpu | head这在多用户服务器上很实用可以快速筛出某个用户名下最吃资源的进程。还有一种情况是你在容器里跑ps aux看到的进程不全那是因为容器通常只有PID namespace内的进程宿主机上的其他进程看不见——这是特性不是bug排查时要跳出容器到宿主机再看。按线程数排序配合查看某个服务的线程打满问题ps -eo pid,nlwp,comm --sort-nlwp | headnlwp是number of kernel threads线程数有的版本叫thcount。如果你发现某个进程线程数异常多比如上千那它大概率在疯狂创建线程或线程池设计不合理。5.3 定时采样与告警脚本别把单次快照当圣旨ps aux --sort-%cpu | head最大的局限性在于它是一张快照。CPU使用率是一个时间变化量单次快照可能受到某个瞬间IO中断、其他进程尖刺的影响。有经验的运维不会拿它做精确的告警源而是拿它做快速定位。我建议的实践做法是写一个简单的 CPU热点采样脚本连拍5次取平均。比如for i in 1 2 3 4 5; do ps -eo pid,pcpu,comm --sort-pcpu | head -n 6 sleep 1 done注意每次采样之间留1秒间隔。然后观察前几名的进程是否稳定地出现在高位。如果一个进程5次采样都占据第一那基本可以认定它是罪魁祸首如果每次排第一的都不同要么是短cpu burst任务在轮换要么是系统负载太高导致的整体调度抖动你要做的就不是定位单个进程而是看全局负载和IO。更进一步可以写成这样一个简短的告警脚本#!/bin/bash # 采集最耗CPU的进程若其CPU连续3次超过阈值则记录日志 THRESHOLD80 for i in 1 2 3; do TOP_PROC$(ps -eo pid,pcpu,comm --sort-pcpu | awk NR2 {print $2}) if [ $(echo $TOP_PROC $THRESHOLD | bc) -eq 1 ]; then COUNT$((COUNT1)) fi sleep 1 done if [ $COUNT -ge 3 ]; then ps aux --sort-%cpu | head -n 10 /var/log/cpu_hot.log fi这个脚本虽然粗糙但它体现了一个原则连续采样确认趋势再下结论。单次快照可以做看看情况做自动化告警就必须考虑瞬时毛刺的干扰。5.4 与top、htop、pidstat的互补关系经常有人问有top为什么还要背ps。我的回答是top是交互式仪表盘适合人盯着屏幕看ps是快照命令行工具适合被脚本调用、输出重定向、远程非交互环境。两者的数据来源都是 /proc底层机制相同只是展示方式和使用场景不同。top的-bbatch mode也可以非交互输出top -b -n 1 -o %CPU | head -n 20但top的 batch 输出制表符多、列宽复杂文本解析没ps -eo来得干净。pidstat 1可以按间隔持续报告每个进程的CPU、内存、IO适合做趋势记录但它不是所有发行版默认安装的需要 sysstat 包。htop交互体验更好有彩色条、树状图但它不一定在精简容器里。所以我的建议是人眼互动用 top/htop脚本和快速定位用 ps深度持续采样用 pidstat三者互补而非替代。5.5 遇到 CPU 占用高但找不到进程的情况这条命令也有失灵的时候最常见的失灵场景其实是lenovo 高CPU但ps aux里每个进程都不高。原因往往有三个一是短命进程进程秒级启动、吃CPU、秒级退出ps aux采样瞬间可能抓不到它但系统CPU总量被推高。这时候用top -d 0.5或者pidstat 1连续采样更容易逮到它也可以用perf top看内核热点或者execsnoop追踪短命进程的启动记录。二是内核线程或内核模块占用ps只能看到用户态进程内核线程大部分也能显示kworker、kswapd等但某些内核模块的CPU消耗、中断处理软中断/硬中断消耗并不体现在进程表里。此时看/proc/softirqs、/proc/interrupts以及top里的%sy、%si、%hi各列才能定位到内核忙。三是被隔离/被限流的进程cgroups的cpu限额、容器配额会影响 %CPU 的计算展示。比如一个进程在容器里被限到0.5核quota 50000/100000它实际打满限额时 %CPU 可能显示50%而不是你想的它在疯狂吃CPU。这种场景下ps里的数值不是假的而是它被允许用到这么多。这些边界情况是我在实际运维中真正踩过的。所以我在教人的时候总把这条命令是起点不是终点挂在嘴边。6. 输出格式化当默认惨不忍睹时用-o自选列ps aux默认输出已经够用了但有两个痛点一是列宽不定命令名超过一定长度就被截断或撑破对齐二是有好多你根本不想看的列VSZ、TTY、STAT等对于写脚本来说显得杂。用-o选项把输出列控制在自己的掌握里属于庖丁解牛之后顺手配一把专属刀具。常用自选列写法# 只显示 PID、CPU、内存、命令名 ps -eo pid,pcpu,pmem,comm --sort-pcpu # 显示完整命令行且不截断 ps -eo pid,pcpu,args --sort-pcpu # 加上线程数和状态便于区分多线程应用 ps -eo pid,pcpu,nlwp,stat,comm --sort-pcpu值得注意的两点comm显示的是命令名默认被截断到15字符args显示完整命令行可带参数也可能因为空格被分成多列——但当你指定args列时它占一整列不会导致后续列错位。解析脚本里用comm更稳妥人眼排查用args更直观。-o语法里也可以使用--sort结合没有任何冲突。-e是所有进程等价于-A。很多人混淆-e和aux其实-e就是所有进程配合-o自选列后它比aux更灵活。给一个一行抓最高CPU的进程PID的用法ps -eo pid,pcpu,comm --sort-pcpu | awk NR2 {print $1}如果第一个进程刚好是标题行那NR2取的就是真正的第一个进程。有时候你可能想排除ps自己因为ps本身也是进程、也会出现在列表里——虽然它通常CPU占用极低不会排进前几名但理论上有洁癖的话可以用grep -v ps或者按命令名过滤掉。7. 从会用到能自查常见疑问与误区清单7.1ps aux和ps -ef的适配场景这是每个学Linux的人都会碰到的问题ps aux、ps -ef到底用哪个-ef是全格式、全进程的SysV风格-e所有进程-f完整格式UID PID PPID C STIME TTY TIME CMD。它的输出没有%CPU和%MEM列所以不适合做资源排序。相反-ef的优势是显示 PPID方便查父子进程关系比如谁把谁fork出来的、某进程的父进程是不是已经变成1号进程。ps aux --sort-%cpu | head和ps -ef --forest是两种完全不同的用途。前者按CPU排序找热点后者按进程树看层级。在这个解牛的主题里我想强调的是别被aux还是ef的口水战带偏看需求选命令。7.2 为什么%CPU之和超过100% 或接近0%在多核机器上所有进程%CPU之和可以等于核数×100%左右不考虑overcommit和调度损耗。所以一台16核机器空闲时所有进程CPU之和可能在0附近满载时则能接近1600%。不要用进程个数 × 100% 来算总负荷那是单核思维。想看系统整体CPU使用情况更直接的是top顶部的%Cpu(s)行或者读/proc/stat的 cpu 行grep ^cpu /proc/stat7.3 为什么ps aux看到的RSS比top里看到的内存小很多RSSResident Set Size是进程实际占用的物理内存量但它不包含共享库中不属于本进程私有的部分被重复计算的问题有些工具显示的是PSS会按共享摊分。当你怀疑某个进程内存占用很高时用%MEM排序不一定能反映真实全貌因为进程之间还有共享内存页。这时可以用smem工具或者读/proc/pid/smaps来统计PSS。这个话题跑远了但它是进程资源排查的一条延伸线提一句免得大家踩坑。7.4 信号与二次开发把ps的输出变成可编程数据源如果你想写一个自动化的CPU热点看门狗不要用ps aux的文本解析硬刚更好的方案是读/proc或者用libprocps很多脚本语言都有对应的绑定库。但日常快速完成一个小工具用ps -eoawk就足够了。我之前写过一个极简的 CPU 热点看门狗每30秒检查一次如果某个进程的CPU超过150%多核阈值且持续3次就发送告警并把相关ps aux快照存到日志。步骤如下# 1. 计算阈值按核心数动态调整 CORES$(nproc) THRESHOLD$(echo $CORES * 0.8 | bc) # 2. 取样 PC$(ps -eo pid,pcpu,comm --sort-pcpu | awk NR2 {print $2}) PNAME$(ps -eo pid,pcpu,comm --sort-pcpu | awk NR2 {print $3}) if [ $(echo $PC $THRESHOLD | bc) -eq 1 ]; then echo $(date) $PNAME($PID) CPU$PC% /var/log/cpu_watch.log fi这种轮询方案在内网小规模排查里完全够用不必一上来就上Prometheus/node_exporter那套重型监控栈。当然如果机器多、需要历史趋势那确实应该用正式监控组件但定位于快速定位单台机器问题轻量脚本反而更直接。8. 结语庖丁解牛的意义在于复用刀法说了这么多最后回到这条命令本身跟我的关系。我最早背下它纯属死记硬背后来搞懂了aux是三个开关的合写、--sort-%cpu是降序键、| head靠 SIGPIPE 提前截断再遇到任何列出来、排个序、取前几条的需求就再也不需要翻文档了。这条命令只是活生生的例子它的刀法可以迁移到ps --sort-%mem看内存、ps -eo pid,nlwp --sort-nlwp看线程数、tail和head的选择、管道死与活的判断……我在实际运维里最吃甜头的一次就是靠这个思路快速定位了一台被某个多线程中间件拖垮的服务器。当时top看整体CPU已经100%但单看每个进程的CPU却都不高正困惑时突然想到短命进程这个坑改用pidstat 1 5连续采样抓到了那个每隔几秒就拉起一批短命线程的进程。而这种思维恰恰是从读懂一条命令的底层解释开始的。如果你现在只是背命令不妨把这篇文章当一次把命令拆到内核的练习。下次再遇到一个看似简单的命令试着问自己每个参数背后在man文档里对应什么含义这个输出在/proc里的哪个文件里算出来的管道左右进程的生死由谁控制能这样问出一串问题你的排查能力就不会停留在抄命令层面了。

庖丁解牛Linux进程排查：ps aux按CPU排序的底层逻辑与实战

相关推荐

从零搭建语义搜索引擎：向量化、Faiss与精排实战

μP理论被新研究推翻？大模型学习率需按深度修正

Excel技巧163条拆解：高频操作、函数图表与避坑实战

更多资讯

深入理解Linux Netlink：内核与用户态通信的协议与实战

TCP吞吐量上不去？抓包实测排查带宽跑不满的实战指南

Linux VM内核参数调优：内存管理、脏页回写与OOM实践

【跟踪】跟踪篇(4)--对于MOT16 Benchmark的理解

STM32F103与AT24C02的I2C读写实战：时序、硬件与调试避坑指南

YOLOv6工业视觉检测优化与部署实战：从能检出到敢上线

今日更新

Verilog实现FPGA密码锁：矩阵键盘与状态机设计实战

数据服务监控运维实战：从指标体系到告警治理与故障排查

FreeRTOS任务通知实战详解：内核原理、API与避坑指南

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？