1. 这不是教科书里的“性能优化”而是我每天在终端里敲出来的排查流水线“排查Linux性能问题一般步骤”——这标题看着平平无奇像极了运维手册里被翻烂的一页。但如果你真在凌晨三点盯着top输出发呆CPU飙到98%却找不到元凶或者客户投诉接口超时你查遍应用日志却只看到一行模糊的“connection reset”又或者数据库慢得像在加载GIF动图而MySQL慢查询日志里偏偏空空如也……这时候你真正需要的不是理论框架而是一套能立刻上手、逐层下钻、不绕弯子的现场作战地图。我干这行十多年从某高校实验室的Linux教学服务器维护到某跨平台系统的SRE岗位再到带团队做高并发中间件稳定性保障踩过的坑基本都刻在bash历史记录里了。所谓“一般步骤”从来不是线性流程图而是一张动态决策网它要能兼容CentOS 7的老旧内核也要适配AlmaLinux 9的eBPF新特性既要处理Java应用堆外内存泄漏这种隐蔽病灶也要快速识别dd命令误操作导致的I/O风暴既得让刚转岗的开发同学看懂iostat输出也得给资深DBA留出perf record深度分析的空间。核心关键词就三个Linux、性能问题、排查步骤——它们不是孤立术语而是一个闭环动作链Linux是战场性能问题是敌情通报排查步骤则是你的战术手册。它不承诺“一键修复”但保证每一步都有明确输入、可验证输出、清晰退出条件。比如当你执行vmstat 1 5后发现si/so列持续非零那就必须进入内存子流程如果pidstat -u 1显示某个进程CPU使用率异常但strace -p却卡在futex_wait那就要立刻切到锁竞争或调度延迟方向。这不是知识罗列而是经验凝结成的条件反射。这篇文章写给三类人一是刚考完RHCE想进真实生产环境的新人你需要知道课本之外的“脏活”怎么干二是写了五年业务代码、突然被拉去救火的开发你得在不惊动架构师的前提下自己定位到是GC停顿还是磁盘IO瓶颈三是带团队的技术负责人你需要一套可复用、可培训、可审计的标准化响应路径。全文没有一句“理论上可以……”所有内容都来自某次线上事故的完整复盘、某次压测中的实时抓包、某台物理机连续72小时的perf数据采样。接下来我们就从第一行命令开始把这张排查地图一格一格铺开。2. 整体设计思路为什么是“五层漏斗”而不是“十大命令”2.1 拒绝“命令堆砌”构建有逻辑纵深的诊断漏斗很多人学Linux性能排查第一步就是背命令top、htop、iostat、vmstat、netstat、sar……结果一上生产环境就懵了——20个窗口同时开着每个都在刷屏数据互相打架。某次某公司线上服务雪崩值班同学贴出的截图里top显示CPU 95%iostat显示await 200msnetstat显示TIME_WAIT过万他问“到底该先看哪个”——这问题本身就暴露了方法论的缺失。我们设计的“五层漏斗”模型本质是模拟人类医生的问诊逻辑先看整体生命体征系统级再查局部症状进程级接着验血拍片资源级然后做病理切片内核级最后基因测序应用级。每一层都设定了明确的排除阈值和升级触发条件避免在错误层级死磕。比如当uptime显示load average远超CPU核心数但mpstat -P ALL 1却显示所有CPU idle都在90%以上那问题必然不在CPU计算资源而是I/O或锁等待——这个判断比盲目杀掉top里排第一的进程靠谱十倍。提示五层漏斗不是固定顺序而是带反馈的决策树。实际操作中你可能从第三层如iotop发现某进程IO异常直接跳回第二层ps aux --sort-%cpu确认进程状态再折返第一层dmesg -T | tail -20检查内核OOM日志。关键在于每一步都有明确的“是/否”出口而非机械执行。2.2 工具选型为什么坚持用原生工具而非全靠PrometheusGrafana现在一提监控必谈Prometheus、Grafana、ELK。它们确实强大但有个致命短板数据是滞后的、聚合的、有采样间隔的。某次某支付系统凌晨出现偶发性3秒延迟监控图表上只看到一条毛刺而真实请求链路里是某个Java线程在获取Redis连接池时卡了2.8秒。等你登录Grafana放大时间轴故障早已过去连接池状态也恢复了。我们的工具链坚持“三原生原则”原生内核接口优先用/proc、/sys文件系统直接读取如cat /proc/$(pidof nginx)/status | grep VmRSS获取精确内存占用比ps的估算值可靠原生系统命令vmstat、pidstat、ss这些随发行版自带的工具无需额外安装版本兼容性好输出格式稳定原生调试能力perf、bpftrace这类内核级工具能穿透用户态抽象直击调度器、页回收、网络栈底层。当然不排斥现代工具。我们会把perf script的输出喂给火焰图生成器把bpftrace的实时事件流推送到轻量级日志中心。但根因定位的起点永远在本地终端。因为真正的性能问题往往发生在监控采样间隙或只影响单个请求的“幽灵线程”上。2.3 为什么跳过“应用日志分析”作为首步——一个血泪教训新手常犯的错误是第一时间扑向应用日志。某次某电商大促订单创建接口超时开发同学花了两小时grep日志结论是“日志没报错应该不是代码问题”。而实际上pidstat -r 1显示JVM进程的%MEM持续攀升pstack $(pidof java)发现大量线程阻塞在java.net.SocketInputStream.socketRead0——根本原因是下游支付网关连接池耗尽上游不断重试建立新连接最终耗光本地端口和内存。这个案例教会我们应用日志是症状描述不是病因报告。它告诉你“哪里疼”但从不解释“为什么疼”。Linux性能排查的第一性原理是相信内核不会说谎——/proc/loadavg的数字、/sys/block/sda/stat的IO计数、/proc/net/snmp的TCP重传统计这些是硬件与内核共同签署的客观证据。日志分析必须放在第四层应用级之后作为交叉验证手段而非起点。3. 核心细节解析五层漏斗的实操要点与避坑指南3.1 第一层系统级宏观扫描——10秒锁定战场范围目标用不超过10秒的命令组合回答三个问题系统是否真的过载过载表现在哪影响范围有多大核心命令组合# 1. 看整体负荷与资源趋势 uptime; echo ---; free -h; echo ---; cat /proc/loadavg # 2. 看CPU实时分布区分用户态/内核态/IO等待 mpstat -P ALL 1 3 | awk NR4 || /Average/ # 3. 看内存水位与交换活动 vmstat 1 3 | tail -1 # 4. 看磁盘IO基础指标 iostat -x 1 3 | grep -E (avg-cpu|sda|nvme) # 5. 看网络连接状态重点TIME_WAIT与连接数 ss -s; ss -tn | wc -l关键解读技巧uptime的load average不能孤立看。需对比nproc输出的核心数若load 2×CPU核心数且持续5分钟才视为严重过载若只是瞬时尖峰可能是正常批处理。free -h里available列才是真实可用内存free列是完全空闲内存常被误解。某次某容器平台告警内存不足free显示仅剩200MB但available仍有3GB——真相是内核缓存占用了大量page cache随时可回收。vmstat的siswap in和soswap out列只要任一列0就说明已发生交换这是内存严重不足的铁证。注意某些云主机启用zramsi/so可能为0但pgpgin/pgpgout飙升需额外检查cat /sys/block/zram0/mm_stat。注意所有命令加-x扩展模式、-P ALL全CPU、-tTCP统计等参数不是为了炫技而是消除默认输出的误导性。例如iostat默认不显示%util和await而这俩是判断磁盘瓶颈的核心。3.2 第二层进程级聚焦——揪出“真凶”还是“替罪羊”目标从数百个进程中精准定位消耗资源的Top 5并区分其行为类型计算密集IO密集内存泄漏核心命令与陷阱top按ShiftPCPU、ShiftM内存、ShiftT运行时间排序但注意其%CPU是采样周期内的平均值对短时爆发进程不敏感。pidstat -u 1比top更准-u显示用户态CPU-k显示内核态-d显示IO-r显示内存。实测发现某Python脚本top显示CPU 30%pidstat -u 1却显示%usr仅5%、%system高达25%——真相是它在疯狂调用os.stat()触发内核路径查找。htop交互式利器但需确认/proc/sys/kernel/kptr_restrict为0否则看不到内核线程名。进程行为分类法实战速判行为类型pidstat特征典型场景快速验证命令计算密集型%usr%system 90%%wait≈0数值计算、加密解密perf top -p PIDIO等待型%wait 50%%usr/%system低数据库查询、大文件读写iotop -p PID内存泄漏型RSS持续增长%MEM缓慢上升Java堆外内存、C new未deletepmap -x PID | tail -5锁竞争型%usr低%system高%wait波动大多线程抢同一mutexperf record -e sched:sched_stat_sleep -p PID避坑心得某次排查Web服务延迟pidstat -u 1显示nginx worker进程CPU 80%但strace -p PID -c统计显示99%时间在epoll_wait——这说明它根本没在干活只是在等事件。真正的问题是上游Nginx配置了worker_connections 1024而ulimit -n只有1024导致连接队列溢出客户端重试风暴。所以高CPU未必是坏事高%wait也不一定是IO瓶颈必须结合上下文看。3.3 第三层资源级深挖——穿透抽象直击硬件与内核目标当确认某类资源CPU/内存/磁盘/网络异常时用底层工具定位具体瓶颈点。CPU瓶颈深挖perf top -a全局查看热点函数-a表示所有CPU。某次发现__do_softirq占比40%顺藤摸瓜查到是网卡软中断处理不过来调整/proc/sys/net/core/netdev_budget并启用RPS后解决。perf record -e cycles,instructions,cache-references,cache-misses -a -- sleep 10采集10秒全系统性能事件perf report可看到指令级缓存命中率判断是否CPU微架构瓶颈。内存瓶颈深挖slabtop看内核slab分配器状态。某次dmesg频繁报slab errorslabtop显示dentry缓存占满80%执行echo 2 /proc/sys/vm/vfs_cache_pressure后缓解。cat /proc/meminfo | grep -E ^(Mem|Swap|Direct|Anon)重点关注AnonPages匿名页即进程堆/栈、Shmem共享内存、SReclaimable可回收slab。若AnonPages持续增长而MemAvailable锐减基本锁定用户态内存泄漏。磁盘IO瓶颈深挖iostat -x 1的await平均IO等待时间100ms需警惕但更要关注svctm服务时间与%util。若await高但svctm低、%util60%说明是队列深度大如RAID卡缓存策略而非磁盘本身慢。blktrace -d /dev/sda -o - | blkparse -i -块层跟踪神器。某次SSD写入延迟突增blkparse输出显示大量Qqueue到Gget request延迟达500ms定位到是NVMe驱动bug升级内核解决。网络瓶颈深挖ss -i显示每个socket的详细指标。retrans重传数、rto重传超时、rcv_space接收窗口是关键。某次TCP重传率高ss -i显示rto从200ms暴涨到2stcpping确认是中间网络设备丢包。cat /proc/net/snmp | grep -A 2 Tcp:看TCP统计。TCPSynRetransSYN重传高说明三次握手失败TCPTimeouts超时连接高说明连接建立后无响应。提示这一层工具输出信息量极大新手易迷失。我的经验是每次只盯1个指标配合1个验证命令。比如看到iostat的%util100%就立刻执行iotop -o看谁在狂刷IO看到ss -i的retrans飙升就马上tcpdump -i eth0 tcp[tcpflags] (tcp-syn|tcp-fin|tcp-rst) ! 0抓包确认。3.4 第四层内核级透视——用eBPF揭开黑盒目标当传统工具无法解释现象时用eBPF动态注入探针观测内核内部行为。eBPF入门三板斧bpftooleBPF程序管理工具。bpftool prog list查看已加载程序bpftool map dump id ID查看BPF map内容。bpftrace高级前端语法类似awk。一行命令解决经典问题# 监控所有进程的open()系统调用失败原因 bpftrace -e tracepoint:syscalls:sys_enter_open { if (args-flags 512) printf(O_CREAT failed for %s: %d\n, str(args-filename), errno); } # 统计每个进程的TCP连接建立耗时从SYN到SYN-ACK bpftrace -e kprobe:tcp_v4_connect { start[tid] nsecs; } kretprobe:tcp_v4_connect /start[tid]/ { $d nsecs - start[tid]; hist[tid] hist($d); delete(start[tid]); }bcc-tools预编译工具集。execsnoop抓新进程、opensnoop抓文件打开、tcplife抓TCP生命周期比strace轻量百倍。真实案例某Java服务偶发GC停顿长达5秒jstat显示Full GC次数极少。perf record -e sched:sched_migrate_task -a -- sleep 30发现大量线程被迁移到不同CPU怀疑NUMA问题。用bpftrace写脚本监控numa_faults事件确认是JVM未配置-XX:UseNUMA导致内存分配跨NUMA节点访问延迟激增。添加JVM参数后GC停顿回归正常。注意eBPF需要内核4.18且/proc/sys/kernel/unprivileged_bpf_disabled需为0。云主机常默认禁用需联系管理员开启。别在生产环境贸然跑bpftrace -e kprobe:* { count(); }这会拖垮系统。3.5 第五层应用级归因——让代码自己开口说话目标将内核观测结果映射回具体代码行、配置项或业务逻辑。Java应用归因jstack PID看线程栈。重点找BLOCKED锁竞争、WAITINGObject.wait、TIMED_WAITINGThread.sleep。某次发现大量线程卡在java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await定位到是线程池拒绝策略配置为CallerRunsPolicy导致主线程被拖慢。jmap -histo PID | head -20看对象实例数。若byte[]、char[]数量暴增大概率是字符串拼接或IO流未关闭。async-profiler比jvisualvm更准的火焰图工具。./profiler.sh -e cpu -d 30 -f /tmp/flame.svg PID生成的SVG可交互下钻。Python应用归因py-spy record -p PID -o /tmp/profile.svg --duration 30无需修改代码直接采样Python栈。gdb -p PID后执行py-bt看Python线程的完整调用栈比pstack更准。通用配置归因lsof -p PID | wc -l对比ulimit -n判断是否文件描述符耗尽。cat /proc/PID/limits | grep Max open files确认进程级限制。strace -p PID -e traceopen,connect,sendto,recvfrom -s 100抓关键系统调用看是否在反复连接失败或读取超时。终极心法第五层不是终点而是闭环的起点。当你用async-profiler发现90%时间花在com.xxx.service.UserService.getUserById下一步必须回到代码查getUserById的SQL是否缺少索引查Redis缓存key是否设计成user:id:123导致穿透查HTTP客户端是否设置了Connection: close性能问题的根因永远在业务逻辑与基础设施的交界处。工具只是手电筒光打在哪取决于你对业务的理解深度。4. 实操过程全记录一次真实的线上CPU飙高故障复盘4.1 故障现象与初始响应00:00-00:03凌晨0点某支付网关告警gateway-serviceCPU使用率持续高于90%持续10分钟。值班同学收到企业微信消息第一反应是kubectl top pod发现Pod CPU limit 4核usage 3.8核接近打满。他SSH登录对应节点执行# 习惯性top看到java进程排第一 top -b -n1 | head -20 # 输出PID 12345 java 98.2% CPU...此时他犯了第一个错误直接kill -9 12345重启服务。服务短暂恢复但3分钟后CPU再次飙升。这违反了排查铁律故障期间禁止任何变更先保现场。4.2 第一层扫描系统级快照00:03-00:08我接手后第一件事是收集基础快照# 同时执行保存到文件 date /tmp/perf-$(date %s).log uptime /tmp/perf-$(date %s).log free -h /tmp/perf-$(date %s).log vmstat 1 5 /tmp/perf-$(date %s).log iostat -x 1 5 /tmp/perf-$(date %s).log ss -s /tmp/perf-$(date %s).log关键发现uptimeload average 12.5, 11.8, 10.2 8核机器明显过载vmstatr列运行队列持续在15-20cs上下文切换高达25000/s正常5000iostat%util仅35%await8ms排除磁盘瓶颈ss -stotal 12000 connections其中TIME-WAIT8500ESTAB3200结论CPU过载但非IO导致连接数高TIME-WAIT多疑似网络连接问题。4.3 第二层聚焦进程级深挖00:08-00:15# 查看java进程的详细CPU分布 pidstat -u -p 12345 1 5 # 输出%usr 15%, %system 82%, %wait 0% # 系统态CPU过高查系统调用 strace -p 12345 -c -s 100 21 | head -20 # 输出% time seconds usecs/call calls errors syscall # 92.12 0.123456 1234 1000 epoll_wait # 5.23 0.005678 56 100 futexepoll_wait占比92%说明进程大部分时间在等事件但%system又高达82%——矛盾继续查# 看线程级CPU top -H -p 12345 -b -n1 | head -20 # 发现线程PID 12346 占用85% CPU且状态为RRunning # 抓该线程的栈 jstack 12345 | grep -A 20 12346 # 输出... at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) # at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269) # at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)真相浮现Java NIO Selector在epoll_wait但%system高说明内核在处理epoll事件时开销大。查/proc/12345/statuscat /proc/12345/status | grep -E Threads|SigQ # Threads: 200 # SigQ: 1024/122880 -- 信号队列已用1024上限122880信号队列没满排除信号积压。再查# 看epoll监听的fd数量 ls -l /proc/12345/fd/ | wc -l # 输出12000 -- 远超ulimit -n 65536? 不是ulimit -n 1024!ulimit -n仅为1024但进程打开了12000 fdstrace显示大量epoll_ctl(EPOLL_CTL_ADD)返回EMFILE打开文件数过多内核被迫在epoll_wait返回前做大量错误处理导致%system虚高。4.4 第三层验证资源级确认00:15-00:20# 确认ulimit cat /proc/12345/limits | grep Max open files # Max open files 1024 1024 files # 查看哪些fd是socket ls -l /proc/12345/fd/ | grep socket | wc -l # 11980 sockets # 查看socket状态分布 ss -tan state established | wc -l # 3200 ESTAB ss -tan state time-wait | wc -l # 8500 TIME-WAIT确认应用创建了海量连接但未正确复用或关闭ulimit -n过低导致epoll_ctl频繁失败内核陷入错误处理循环。4.5 第五层归因代码与配置修复00:20-00:30代码层审计发现HTTP客户端未配置连接池每次请求新建HttpClient且未调用close()。配置层JVM启动参数未设置-XX:MaxFDLimit无法突破系统ulimit。系统层/etc/security/limits.conf中* soft nofile 65536未生效因服务由systemd启动需在/etc/systemd/system/gateway.service中加[Service] LimitNOFILE65536修复步骤紧急prlimit --nofile65536 --pid 12345临时提升限制代码引入Apache HttpClient连接池设置maxConnPerRoute20,maxConnTotal200配置更新systemd service文件重载并重启验证curl -s http://localhost:8080/actuator/metrics/http.client.requests | jq .measurements[].value确认请求数平稳。效果CPU从98%降至15%epoll_wait占比从92%降至5%%system从82%降至8%。故障根除。5. 常见问题与独家排查技巧实录5.1 “CPU使用率100%但找不到高CPU进程”——幽灵CPU问题现象top显示CPU 100%但所有进程%CPU加起来不到20%。排查路径mpstat -P ALL 1看是否单个CPU核心100%其他核心idle。若是可能是该核绑定的中断过于密集。cat /proc/interrupts | grep -E (eth|nvme|ahci)看网卡/NVMe中断是否集中在某CPU。某次eth0中断90%落在CPU0执行# 将eth0中断均衡到所有CPU echo ffffff /proc/irq/$(cat /proc/interrupts | grep eth0 | head -1 | awk {print $1} | sed s/://)/smp_affinity_listperf record -e cycles,instructions -a -- sleep 10 perf report看[kernel.kallsyms]下的函数如native_safe_haltCPU空转、cpuidle_enter_state空闲状态确认是否在空转。独家技巧用stress-ng --cpu 1 --timeout 10s制造可控CPU负载对比perf report输出建立“健康基线”。5.2 “内存充足但频繁OOM Killer”——内存碎片化陷阱现象free -h显示available4GB但dmesg持续报Out of memory: Kill process java。根源内核内存管理中kmalloc分配小内存128KB走slab大内存128KB走buddy system。当buddy system中order-38页及以上连续内存块不足时即使总内存充裕也会OOM。验证命令# 查看buddy system各阶空闲页数 cat /proc/buddyinfo # 输出Node 0, zone DMA 123 45 23 12 5 2 1 0 0 0 0 # Node 0, zone Normal 567 234 102 45 12 3 0 0 0 0 0 # 关键看最后一列order-104MB块若为0且PageAlloc失败日志多则是碎片化 # 查看内存碎片指数 cat /sys/kernel/debug/extfrag/extfrag_index # 值越接近0碎片越严重解决方案临时echo 1 /proc/sys/vm/compact_memory触发内存整理长期调整vm.min_free_kbytes增大预留内存减少碎片或启用CONFIG_COMPACTIONy内核配置。5.3 “网络延迟高但ping正常”——TCP栈参数失配现象ping延迟1ms但curl请求耗时3秒ss -i显示rto从200ms涨到2000ms。排查重点sysctl net.ipv4.tcp_rmemrmem_default应≥应用接收缓冲区否则recv()阻塞sysctl net.core.rmem_max必须≥tcp_rmem第三值否则setsockopt(SO_RCVBUF)失败ss -i的rcv_space若远小于rmem_default说明应用未调用setsockopt(SO_RCVBUF)或内核限制。实操技巧用tc qdisc add dev eth0 root netem delay 100ms在测试环境模拟高延迟观察ss -i中rto变化规律反向推导生产环境参数。5.4 “磁盘IO等待高但iostat不报警”——队列深度幻觉现象iostat -x显示%util40%await15ms但应用日志报“DB query timeout”。真相%util是设备忙时间占比对SSD意义不大await是平均等待时间掩盖了长尾。某次NVMe盘await12ms但P99延迟达500ms。破局工具iostat -x -d 1加-d显示设备名避免RAID虚拟设备干扰blktracebiolatency.pybcc工具生成IO延迟直方图看P99/P999cat /sys/block/nvme0n1/queue/nr_requests检查队列深度NVMe默认256可调至1024。我的经验对SSDawait参考价值低紧盯biolatency.py输出的usecs列100000100ms即需干预。5.5 “排查步骤执行完仍无解”——终极兜底方案当五层漏斗都走过问题依旧按此清单逐项核对确认时间同步ntpq -p时间不同步会导致SSL证书校验失败、分布式锁异常检查SELinux/AppArmorsestatusausearch -m avc -ts recent权限拦截常表现为“Operation not permitted”验证硬件健康smartctl -a /dev/sda磁盘、ipmitool sensor服务器传感器、memtester 1G 1内存压力测试内核版本陷阱uname -r某些老内核如3.10.0-327有已知调度器bug升级内核是唯一解容器逃逸嫌疑ls -l /proc/1/ns/对比宿主机/proc/1/ns/若不一致可能被容器逃逸攻击。最后分享一个小技巧把本文的五层漏斗做成一张A4纸速查表贴在显示器边框。每次故障就按表打钩强迫自己不跳步。我带过的十几位新人用这个方法平均故障定位时间从2小时缩短到20分钟。技术没有捷径但有经过验证的路径。