1. 项目概述为什么我们需要一套自己的性能工具箱在Linux服务器上折腾了十几年从早期的单核机器到现在的几百个核心的云实例我最大的感触就是性能问题永远不会消失它只会以新的形式出现。你可能会遇到应用响应突然变慢、数据库查询超时、或者整台机器的CPU使用率莫名其妙地冲到100%。这时候临时抱佛脚去搜索“Linux 性能分析命令”往往来不及而且网上的信息鱼龙混杂有些命令参数已经过时有些分析思路根本不对症。“Linux性能工具分享”这个标题背后远不止是罗列几个top、vmstat的命令行。它真正的价值在于构建一套属于你自己或者你团队的、系统化的性能问题排查心智模型和工具链。这套东西不是用来炫技的而是在关键时刻能帮你快速定位到瓶颈点从“大概可能是某个服务有问题”的模糊状态推进到“是Java应用在Full GC原因是堆内存设置过小且存在内存泄漏”的精确诊断。我见过很多运维和开发同学知道不少命令但遇到真实的生产环境问题依然会手忙脚乱。问题往往出在工具是零散的思路是片段的。今天我想分享的不仅仅是我常用的工具列表更是一套从全局到局部、从现象到根因的“性能侦探”工作流。这套方法融合了多年的踩坑经验目标是让你手里拿着的不是一把把孤立的螺丝刀而是一整套适配各种故障场景的“瑞士军刀”。2. 性能分析的核心方法论从USE到RED在具体介绍工具之前我们必须先统一思想。没有方法的工具使用就像在迷宫里乱转。在业界有两个我非常推崇且在实践中反复验证过的模型。2.1 USE方法针对系统资源瓶颈的“体检表”USE是Utilization使用率、Saturation饱和度、Errors错误率的缩写。它由性能工程大师Brendan Gregg提出专门用于快速检查系统资源是否成为瓶颈。它的思路异常清晰针对每一个系统资源如CPU、内存、磁盘、网络依次询问三个问题。使用率该资源忙于工作的平均时间百分比是多少例如CPU使用率70%。饱和度资源因排队而无法服务额外工作的程度如何例如CPU运行队列长度load average远高于CPU核心数。错误率发生错误的数量或频率是多少例如网卡CRC错误、磁盘读写错误。这个方法的强大之处在于它的系统性和穷尽性。你只需要列一张所有硬件和软件资源的清单然后对每一项套用这三个问题。通过这种方式你几乎不可能遗漏主要的性能瓶颈源。在我的实践中我通常会准备一张简化的CHECKLIST表格在发生性能告警时快速过一遍资源类别具体资源使用率检查点饱和度检查点错误率检查点对应关键工具/命令CPU单个CPU核心mpstat -P ALL 1vmstat 1(看r列)N/A (通常无)mpstat,top,pidstat内存物理内存free -m/vmstat 1vmstat 1(看si/so列0)N/Afree,vmstat,sar -B存储磁盘设备如/dev/sdaiostat -xz 1(%util)iostat -xz 1(await,avgqu-sz)iostat -xz 1(svctm异常高) /dmesgiostat,iotop网络网络接口如eth0sar -n DEV 1(rxkB/s,txkB/s)端口连接数 (ss -s) 丢包 (sar -n EDEV 1)sar -n EDEV 1(rxerr/s,txerr/s)sar,ss,ethtool注意%util在iostat中达到100%并不一定意味着磁盘饱和。对于现代SSD或RAID阵列更需要关注await平均I/O等待时间和avgqu-sz平均队列长度这两个饱和度指标。如果await远高于设备典型的响应时间如SSD通常应1ms即使%util不高也意味着应用正在经历存储延迟。2.2 RED方法针对微服务与应用的“健康度仪表盘”随着微服务和云原生的普及我们更关注的是服务的性能而不仅仅是底层资源。RED方法Rate, Errors, Duration就是为此而生它被广泛用于监控像API服务、数据库请求这样的业务端点。Rate速率你的服务每秒处理的请求数。例如QPS每秒查询数或RPS每秒请求数。Errors错误率每秒失败的请求数量或失败请求的百分比。Duration耗时处理每个请求所花费的时间通常我们关注其分布如P50中位数、P95、P99分位数。RED方法让你从用户的视角看待性能。一个系统的CPU、内存可能都很健康但如果应用代码存在慢查询或死锁用户的请求延迟Duration就会飙升错误率Errors也可能随之升高。将USE和RED结合就形成了一套从基础设施到应用服务的完整观测体系先用USE法快速排除硬件和OS层面的瓶颈再用RED法深入剖析应用逻辑本身的问题。3. 工具箱详解从“第一现场”到“深度剖析”有了方法论我们来看看工具箱里的“家伙事儿”。我会按照问题排查的一般流程来组织这些工具从最宏观的整体状态查看到具体资源的深入分析再到进程和代码级别的 profiling。3.1 第一响应工具快速俯瞰系统全局当告警响起你需要最快速度了解系统到底在经历什么。以下命令能让你在30秒内形成初步判断。uptime/top/htopuptime命令输出的最后三个数字是系统的平均负载。这是一个非常经典但也极易被误解的指标。它代表的是处于可运行状态R状态和不可中断睡眠状态D状态的进程平均数。简单来说如果1分钟负载远高于5分钟、15分钟负载说明有一个突发的压力。关键解读平均负载理想情况下应接近CPU逻辑核心数。如果持续高于核心数的2-3倍说明系统已经过载进程需要排队等待CPU。top是真正的全能选手。启动后我第一眼会看首部汇总信息load average印证uptime%Cpu(s)行看us用户态、sy系统态、id空闲、waI/O等待。如果wa长期很高说明磁盘是瓶颈。进程列表默认按CPU排序能立刻揪出“罪魁祸首”。按M可以切换为按内存排序。htop是top的增强版界面更友好支持鼠标操作和树状视图查看进程父子关系非常方便。vmstat 1这是一个被低估的利器。vmstat 1表示每1秒输出一次摘要。重点关注这几列r可运行进程数是CPU饱和度的直接体现对应USE中的饱和度。si/so每秒从磁盘交换区读入/写出的内存量单位KB。只要si或so持续大于0就说明物理内存不足发生了交换这会导致性能急剧下降这是内存饱和度的铁证。us,sy,id,wa,stCPU时间分解与top类似。dmesg -T | tail系统内核的“黑匣子”。很多硬件错误如磁盘坏道、OOM内存溢出杀死进程等关键事件都会在这里留下日志。性能问题排查时一定要看一眼最后几条信息说不定有意外发现。3.2 资源专项诊断工具当全局视角发现某个资源指标异常后就需要使用专项工具进行深入诊断。CPU深度分析mpstat与pidstattop告诉你哪个进程吃CPU但mpstat -P ALL 1能告诉你每个CPU核心的详细情况。这在诊断多核CPU使用不均、或者单个进程的线程只跑满一个核心的场景时非常有用。pidstat是更强大的进程资源统计工具。例如pidstat -urd -p PID 1可以每秒输出一次指定进程的CPU、内存、磁盘I/O详情。如果你想查看所有进程的CPU使用pidstat -u 1比top提供更清晰、时间序列化的视图。内存深度分析free与/proc/meminfofree -m大家都会用但要看懂需要理解Linux的内存管理哲学尽可能利用内存做缓存Cache和缓冲Buffer。所以used很高不一定有问题关键看available可用内存和free完全空闲内存。available才是系统认为真正可分配给新进程的内存估计值。更详细的信息在/proc/meminfo里。比如Slab内核对象缓存占用过大可能是内核模块或文件系统有内存泄漏SUnreclaim不可回收的Slab持续增长是危险信号。I/O深度分析iostat与iotopiostat -xz 1是磁盘I/O分析的黄金命令。%util设备利用率百分比。如前所述需谨慎解读。await平均I/O等待时间毫秒。这是应用感受到的延迟是关键指标。avgqu-sz平均队列长度。队列越长饱和度越高。r/s,w/s每秒读写次数。rkB/s,wkB/s每秒读写数据量。如果iostat发现某个设备await很高接下来就用iotop需要root来定位是哪个进程在进行大量I/O操作。它的界面类似top但显示的是进程的磁盘读写速率。网络深度分析sar与sssarSystem Activity Reporter是历史数据分析的王者但它也能做实时监控。sar -n DEV 1可以每秒查看所有网络接口的吞吐量rxkB/s,txkB/s、包量以及错误和丢包情况。ss是netstat的现代替代品速度更快信息更全。ss -tlnp查看所有监听端口及其对应进程ss -s查看整体的socket统计摘要包括TCP连接状态数量对于排查连接数过多如TIME_WAIT堆积的问题非常有用。3.3 应用级与进程内部分析工具当定位到问题进程后我们需要知道它在“里面”到底在干什么。strace/perf系统调用与性能事件分析strace -p PID可以动态跟踪一个进程发起的所有系统调用。这对于诊断进程卡在某个I/O操作如read、write、connect、或者频繁进行某些系统调用时非常有效。但要注意strace开销很大不适合长时间在生产环境使用。perf是Linux内核自带的性能分析神器功能极其强大。perf top可以实时查看整个系统中哪些函数占用CPU最多。perf record -g -p PID可以采样指定进程的性能数据如CPU周期然后通过perf report生成火焰图直观地展示出CPU时间都花在了哪条调用路径上。这是定位应用代码热点Hotspot的终极武器之一。jstack/arthasJava应用专项对于Java应用jstack pid可以打印出JVM内所有线程的堆栈信息。当CPU高时你可以快速找到是哪些线程在运行对应什么业务代码如处于RUNNABLE状态的线程在执行什么方法。当应用无响应时可以检查是否有死锁deadlock。阿里开源的Arthas更是运维Java应用的瑞士军刀。它可以在不重启JVM的情况下进行动态日志级别调整、方法执行耗时监控trace、反编译线上代码、甚至修改运行中的代码mc/redefine慎用。例如使用trace demo.MathGame run命令可以清晰地看到run方法内部每一个子调用的耗时精准定位慢逻辑。tcpdump/Wireshark网络包分析当怀疑网络问题是罪魁祸首时如延迟高、丢包、应用协议异常必须祭出包分析工具。tcpdump -i eth0 -w capture.pcap port 80可以在服务器上抓取80端口的流量并保存为文件。然后将capture.pcap文件下载到本地用图形化的Wireshark打开进行分析。你可以清晰地看到TCP三次握手是否缓慢、是否有重传、HTTP请求响应是否完整、业务报文格式是否正确。这是解决复杂网络交互问题的“显微镜”。4. 实战演练一个经典的高CPU问题排查流程让我们用一个模拟的真实案例把上面的工具串起来用一遍。场景收到监控告警某台线上服务器的CPU使用率持续超过90%。第一步全局状态确认30秒内ssh登录服务器首先运行uptime。发现load average为35.2, 28.1, 15.5而机器是8核CPU。负载远高于核心数确认CPU饱和。运行top。看到%Cpu(s)行us高达70%sy占20%id只剩10%。说明主要是用户态应用吃掉了CPU。在top的进程列表中排第一的是一个Java进程CPU占用380%因为是8核所以一个进程可以超过100%。记下它的PID比如12345。第二步深入分析问题进程我们已经知道PID是12345。用htop并切换到树状视图查看这个Java进程下的所有线程。可能会发现有几个线程CPU占用特别高。为了获取Java线程的详细信息我们使用jstack 12345 jstack.log。但jstack输出的线程ID是十六进制的nid需要转换。在top或htop中可以看到高CPU线程的PIDLWP轻量级进程ID。例如线程PID是12346。将十进制PID12346转为十六进制printf “%x\n” 12346得到0x303a。在jstack.log文件中搜索nid0x303a。找到了这个线程的堆栈显示它正在执行com.example.service.ReportGenerator.generate()方法并且处于RUNNABLE状态。第三步定位代码热点光知道在哪个方法还不够我们需要知道这个方法里面哪一行、哪个子调用最耗时。此时如果环境允许可以上Arthas。连接上目标JVM后执行trace com.example.service.ReportGenerator generate。Arthas会打印出该方法内部调用的耗时分布。我们发现generate方法内部调用了dataQuery方法而dataQuery方法耗时占到了95%。继续trace这个dataQuery方法最终发现时间都花在了一个复杂的、没有加索引的SQL查询上。第四步根因与解决根因定位高CPU是由于一个Java业务线程在执行一个效率极低的数据库查询该查询消耗了大量CPU时间进行数据计算和遍历。 解决方案并非立即重启或扩容。而是优化该SQL语句添加合适的索引。检查该查询是否必要能否增加缓存。考虑对该耗时任务进行异步化处理避免阻塞主线程。实操心得在整个过程中vmstat和iostat可以并行运行以排除内存和I/O瓶颈。如果jstack没有发现问题比如线程都在WAITING状态那么可能需要使用perf来查看CPU周期到底消耗在哪些内核或用户态函数上可能是某些本地库如加密解密或JVM自身如GC导致了CPU高。排查路径不是唯一的需要根据现场证据灵活调整。5. 性能数据可视化与长期监控临阵磨枪的工具箱很重要但完善的监控系统才能让你防患于未然。将上面提到的USE和RED指标通过PrometheusGrafana或Zabbix等监控系统持续采集和可视化是运维工作的基石。关键指标看板建议主机层CPU使用率/负载、内存可用量、磁盘使用率/I/O延迟、网络带宽/丢包率。容器层如果适用容器CPU/内存限制与使用量。应用层RED指标关键接口的请求QPS、错误率、P95/P99延迟。中间件层数据库连接数、慢查询数量、消息队列堆积长度、缓存命中率。当这些指标出现异常趋势如延迟曲线缓慢爬升时你就能在用户投诉之前提前介入调查利用前面介绍的工具进行深度剖析这才是性能管理的最高境界。6. 常见陷阱与排查技巧实录陷阱一平均负载高但CPU使用率低这通常意味着瓶颈不在CPU而在I/O或锁。进程因为等待磁盘I/OD状态或锁S状态而阻塞它们虽然不消耗CPU但依然计入负载。此时应立刻检查vmstat的waI/O等待和b阻塞进程列并用iostat查看磁盘状态。陷阱二free内存几乎为0但应用运行正常这是Linux的正常现象。如前所述内核会用空闲内存做缓存。只要available内存充足free内存少完全不用担心。监控应关注available而非free。陷阱三jstack没发现死锁但应用线程全部卡住可能是遇到了“活锁”或资源池耗尽。检查数据库连接池、HTTP客户端连接池是否已满。也可以使用jstack多抓几次堆栈对比看线程状态是否有变化如果全部卡在同一个地方如等待数据库连接那很可能就是池化资源瓶颈。排查技巧保存现场在重启问题进程或机器前务必先保存现场信息这对事后复盘至关重要。一个简单的现场保存脚本可以包含以下命令#!/bin/bash DATE$(date %Y%m%d_%H%M%S) DIR/tmp/investigation_$DATE mkdir -p $DIR cd $DIR top -b -n 1 top.log vmstat 1 10 vmstat.log iostat -xz 1 10 iostat.log ps aux ps.log netstat -antp netstat.log # 或 ss -antp ss.log jstack PID jstack.log 21 # 如果是Java应用 # ... 其他必要命令 tar -czf ../investigation_$DATE.tar.gz .这个压缩包就是事故现场的“快照”包含了问题发生时最关键的系统状态。性能优化和问题排查是一个永无止境的学习过程。工具是死的思路是活的。我最深的体会是不要死记硬背命令参数而是要理解每个工具输出的每一个字段代表什么物理意义以及它们之间如何相互印证。当你拿到一个性能问题能像侦探一样从监控大盘的异常指标线索出发熟练地运用USE/RED方法论组织你的调查方向并精准地选取top-pidstat-jstack/perf这样的工具链层层深入最终定位到一行代码或一个配置时那种成就感是无与伦比的。这套工具箱和思考方式希望能成为你在Linux世界里解决性能谜题的可靠伙伴。
Linux性能排查实战：从USE/RED方法论到工具链深度解析
1. 项目概述为什么我们需要一套自己的性能工具箱在Linux服务器上折腾了十几年从早期的单核机器到现在的几百个核心的云实例我最大的感触就是性能问题永远不会消失它只会以新的形式出现。你可能会遇到应用响应突然变慢、数据库查询超时、或者整台机器的CPU使用率莫名其妙地冲到100%。这时候临时抱佛脚去搜索“Linux 性能分析命令”往往来不及而且网上的信息鱼龙混杂有些命令参数已经过时有些分析思路根本不对症。“Linux性能工具分享”这个标题背后远不止是罗列几个top、vmstat的命令行。它真正的价值在于构建一套属于你自己或者你团队的、系统化的性能问题排查心智模型和工具链。这套东西不是用来炫技的而是在关键时刻能帮你快速定位到瓶颈点从“大概可能是某个服务有问题”的模糊状态推进到“是Java应用在Full GC原因是堆内存设置过小且存在内存泄漏”的精确诊断。我见过很多运维和开发同学知道不少命令但遇到真实的生产环境问题依然会手忙脚乱。问题往往出在工具是零散的思路是片段的。今天我想分享的不仅仅是我常用的工具列表更是一套从全局到局部、从现象到根因的“性能侦探”工作流。这套方法融合了多年的踩坑经验目标是让你手里拿着的不是一把把孤立的螺丝刀而是一整套适配各种故障场景的“瑞士军刀”。2. 性能分析的核心方法论从USE到RED在具体介绍工具之前我们必须先统一思想。没有方法的工具使用就像在迷宫里乱转。在业界有两个我非常推崇且在实践中反复验证过的模型。2.1 USE方法针对系统资源瓶颈的“体检表”USE是Utilization使用率、Saturation饱和度、Errors错误率的缩写。它由性能工程大师Brendan Gregg提出专门用于快速检查系统资源是否成为瓶颈。它的思路异常清晰针对每一个系统资源如CPU、内存、磁盘、网络依次询问三个问题。使用率该资源忙于工作的平均时间百分比是多少例如CPU使用率70%。饱和度资源因排队而无法服务额外工作的程度如何例如CPU运行队列长度load average远高于CPU核心数。错误率发生错误的数量或频率是多少例如网卡CRC错误、磁盘读写错误。这个方法的强大之处在于它的系统性和穷尽性。你只需要列一张所有硬件和软件资源的清单然后对每一项套用这三个问题。通过这种方式你几乎不可能遗漏主要的性能瓶颈源。在我的实践中我通常会准备一张简化的CHECKLIST表格在发生性能告警时快速过一遍资源类别具体资源使用率检查点饱和度检查点错误率检查点对应关键工具/命令CPU单个CPU核心mpstat -P ALL 1vmstat 1(看r列)N/A (通常无)mpstat,top,pidstat内存物理内存free -m/vmstat 1vmstat 1(看si/so列0)N/Afree,vmstat,sar -B存储磁盘设备如/dev/sdaiostat -xz 1(%util)iostat -xz 1(await,avgqu-sz)iostat -xz 1(svctm异常高) /dmesgiostat,iotop网络网络接口如eth0sar -n DEV 1(rxkB/s,txkB/s)端口连接数 (ss -s) 丢包 (sar -n EDEV 1)sar -n EDEV 1(rxerr/s,txerr/s)sar,ss,ethtool注意%util在iostat中达到100%并不一定意味着磁盘饱和。对于现代SSD或RAID阵列更需要关注await平均I/O等待时间和avgqu-sz平均队列长度这两个饱和度指标。如果await远高于设备典型的响应时间如SSD通常应1ms即使%util不高也意味着应用正在经历存储延迟。2.2 RED方法针对微服务与应用的“健康度仪表盘”随着微服务和云原生的普及我们更关注的是服务的性能而不仅仅是底层资源。RED方法Rate, Errors, Duration就是为此而生它被广泛用于监控像API服务、数据库请求这样的业务端点。Rate速率你的服务每秒处理的请求数。例如QPS每秒查询数或RPS每秒请求数。Errors错误率每秒失败的请求数量或失败请求的百分比。Duration耗时处理每个请求所花费的时间通常我们关注其分布如P50中位数、P95、P99分位数。RED方法让你从用户的视角看待性能。一个系统的CPU、内存可能都很健康但如果应用代码存在慢查询或死锁用户的请求延迟Duration就会飙升错误率Errors也可能随之升高。将USE和RED结合就形成了一套从基础设施到应用服务的完整观测体系先用USE法快速排除硬件和OS层面的瓶颈再用RED法深入剖析应用逻辑本身的问题。3. 工具箱详解从“第一现场”到“深度剖析”有了方法论我们来看看工具箱里的“家伙事儿”。我会按照问题排查的一般流程来组织这些工具从最宏观的整体状态查看到具体资源的深入分析再到进程和代码级别的 profiling。3.1 第一响应工具快速俯瞰系统全局当告警响起你需要最快速度了解系统到底在经历什么。以下命令能让你在30秒内形成初步判断。uptime/top/htopuptime命令输出的最后三个数字是系统的平均负载。这是一个非常经典但也极易被误解的指标。它代表的是处于可运行状态R状态和不可中断睡眠状态D状态的进程平均数。简单来说如果1分钟负载远高于5分钟、15分钟负载说明有一个突发的压力。关键解读平均负载理想情况下应接近CPU逻辑核心数。如果持续高于核心数的2-3倍说明系统已经过载进程需要排队等待CPU。top是真正的全能选手。启动后我第一眼会看首部汇总信息load average印证uptime%Cpu(s)行看us用户态、sy系统态、id空闲、waI/O等待。如果wa长期很高说明磁盘是瓶颈。进程列表默认按CPU排序能立刻揪出“罪魁祸首”。按M可以切换为按内存排序。htop是top的增强版界面更友好支持鼠标操作和树状视图查看进程父子关系非常方便。vmstat 1这是一个被低估的利器。vmstat 1表示每1秒输出一次摘要。重点关注这几列r可运行进程数是CPU饱和度的直接体现对应USE中的饱和度。si/so每秒从磁盘交换区读入/写出的内存量单位KB。只要si或so持续大于0就说明物理内存不足发生了交换这会导致性能急剧下降这是内存饱和度的铁证。us,sy,id,wa,stCPU时间分解与top类似。dmesg -T | tail系统内核的“黑匣子”。很多硬件错误如磁盘坏道、OOM内存溢出杀死进程等关键事件都会在这里留下日志。性能问题排查时一定要看一眼最后几条信息说不定有意外发现。3.2 资源专项诊断工具当全局视角发现某个资源指标异常后就需要使用专项工具进行深入诊断。CPU深度分析mpstat与pidstattop告诉你哪个进程吃CPU但mpstat -P ALL 1能告诉你每个CPU核心的详细情况。这在诊断多核CPU使用不均、或者单个进程的线程只跑满一个核心的场景时非常有用。pidstat是更强大的进程资源统计工具。例如pidstat -urd -p PID 1可以每秒输出一次指定进程的CPU、内存、磁盘I/O详情。如果你想查看所有进程的CPU使用pidstat -u 1比top提供更清晰、时间序列化的视图。内存深度分析free与/proc/meminfofree -m大家都会用但要看懂需要理解Linux的内存管理哲学尽可能利用内存做缓存Cache和缓冲Buffer。所以used很高不一定有问题关键看available可用内存和free完全空闲内存。available才是系统认为真正可分配给新进程的内存估计值。更详细的信息在/proc/meminfo里。比如Slab内核对象缓存占用过大可能是内核模块或文件系统有内存泄漏SUnreclaim不可回收的Slab持续增长是危险信号。I/O深度分析iostat与iotopiostat -xz 1是磁盘I/O分析的黄金命令。%util设备利用率百分比。如前所述需谨慎解读。await平均I/O等待时间毫秒。这是应用感受到的延迟是关键指标。avgqu-sz平均队列长度。队列越长饱和度越高。r/s,w/s每秒读写次数。rkB/s,wkB/s每秒读写数据量。如果iostat发现某个设备await很高接下来就用iotop需要root来定位是哪个进程在进行大量I/O操作。它的界面类似top但显示的是进程的磁盘读写速率。网络深度分析sar与sssarSystem Activity Reporter是历史数据分析的王者但它也能做实时监控。sar -n DEV 1可以每秒查看所有网络接口的吞吐量rxkB/s,txkB/s、包量以及错误和丢包情况。ss是netstat的现代替代品速度更快信息更全。ss -tlnp查看所有监听端口及其对应进程ss -s查看整体的socket统计摘要包括TCP连接状态数量对于排查连接数过多如TIME_WAIT堆积的问题非常有用。3.3 应用级与进程内部分析工具当定位到问题进程后我们需要知道它在“里面”到底在干什么。strace/perf系统调用与性能事件分析strace -p PID可以动态跟踪一个进程发起的所有系统调用。这对于诊断进程卡在某个I/O操作如read、write、connect、或者频繁进行某些系统调用时非常有效。但要注意strace开销很大不适合长时间在生产环境使用。perf是Linux内核自带的性能分析神器功能极其强大。perf top可以实时查看整个系统中哪些函数占用CPU最多。perf record -g -p PID可以采样指定进程的性能数据如CPU周期然后通过perf report生成火焰图直观地展示出CPU时间都花在了哪条调用路径上。这是定位应用代码热点Hotspot的终极武器之一。jstack/arthasJava应用专项对于Java应用jstack pid可以打印出JVM内所有线程的堆栈信息。当CPU高时你可以快速找到是哪些线程在运行对应什么业务代码如处于RUNNABLE状态的线程在执行什么方法。当应用无响应时可以检查是否有死锁deadlock。阿里开源的Arthas更是运维Java应用的瑞士军刀。它可以在不重启JVM的情况下进行动态日志级别调整、方法执行耗时监控trace、反编译线上代码、甚至修改运行中的代码mc/redefine慎用。例如使用trace demo.MathGame run命令可以清晰地看到run方法内部每一个子调用的耗时精准定位慢逻辑。tcpdump/Wireshark网络包分析当怀疑网络问题是罪魁祸首时如延迟高、丢包、应用协议异常必须祭出包分析工具。tcpdump -i eth0 -w capture.pcap port 80可以在服务器上抓取80端口的流量并保存为文件。然后将capture.pcap文件下载到本地用图形化的Wireshark打开进行分析。你可以清晰地看到TCP三次握手是否缓慢、是否有重传、HTTP请求响应是否完整、业务报文格式是否正确。这是解决复杂网络交互问题的“显微镜”。4. 实战演练一个经典的高CPU问题排查流程让我们用一个模拟的真实案例把上面的工具串起来用一遍。场景收到监控告警某台线上服务器的CPU使用率持续超过90%。第一步全局状态确认30秒内ssh登录服务器首先运行uptime。发现load average为35.2, 28.1, 15.5而机器是8核CPU。负载远高于核心数确认CPU饱和。运行top。看到%Cpu(s)行us高达70%sy占20%id只剩10%。说明主要是用户态应用吃掉了CPU。在top的进程列表中排第一的是一个Java进程CPU占用380%因为是8核所以一个进程可以超过100%。记下它的PID比如12345。第二步深入分析问题进程我们已经知道PID是12345。用htop并切换到树状视图查看这个Java进程下的所有线程。可能会发现有几个线程CPU占用特别高。为了获取Java线程的详细信息我们使用jstack 12345 jstack.log。但jstack输出的线程ID是十六进制的nid需要转换。在top或htop中可以看到高CPU线程的PIDLWP轻量级进程ID。例如线程PID是12346。将十进制PID12346转为十六进制printf “%x\n” 12346得到0x303a。在jstack.log文件中搜索nid0x303a。找到了这个线程的堆栈显示它正在执行com.example.service.ReportGenerator.generate()方法并且处于RUNNABLE状态。第三步定位代码热点光知道在哪个方法还不够我们需要知道这个方法里面哪一行、哪个子调用最耗时。此时如果环境允许可以上Arthas。连接上目标JVM后执行trace com.example.service.ReportGenerator generate。Arthas会打印出该方法内部调用的耗时分布。我们发现generate方法内部调用了dataQuery方法而dataQuery方法耗时占到了95%。继续trace这个dataQuery方法最终发现时间都花在了一个复杂的、没有加索引的SQL查询上。第四步根因与解决根因定位高CPU是由于一个Java业务线程在执行一个效率极低的数据库查询该查询消耗了大量CPU时间进行数据计算和遍历。 解决方案并非立即重启或扩容。而是优化该SQL语句添加合适的索引。检查该查询是否必要能否增加缓存。考虑对该耗时任务进行异步化处理避免阻塞主线程。实操心得在整个过程中vmstat和iostat可以并行运行以排除内存和I/O瓶颈。如果jstack没有发现问题比如线程都在WAITING状态那么可能需要使用perf来查看CPU周期到底消耗在哪些内核或用户态函数上可能是某些本地库如加密解密或JVM自身如GC导致了CPU高。排查路径不是唯一的需要根据现场证据灵活调整。5. 性能数据可视化与长期监控临阵磨枪的工具箱很重要但完善的监控系统才能让你防患于未然。将上面提到的USE和RED指标通过PrometheusGrafana或Zabbix等监控系统持续采集和可视化是运维工作的基石。关键指标看板建议主机层CPU使用率/负载、内存可用量、磁盘使用率/I/O延迟、网络带宽/丢包率。容器层如果适用容器CPU/内存限制与使用量。应用层RED指标关键接口的请求QPS、错误率、P95/P99延迟。中间件层数据库连接数、慢查询数量、消息队列堆积长度、缓存命中率。当这些指标出现异常趋势如延迟曲线缓慢爬升时你就能在用户投诉之前提前介入调查利用前面介绍的工具进行深度剖析这才是性能管理的最高境界。6. 常见陷阱与排查技巧实录陷阱一平均负载高但CPU使用率低这通常意味着瓶颈不在CPU而在I/O或锁。进程因为等待磁盘I/OD状态或锁S状态而阻塞它们虽然不消耗CPU但依然计入负载。此时应立刻检查vmstat的waI/O等待和b阻塞进程列并用iostat查看磁盘状态。陷阱二free内存几乎为0但应用运行正常这是Linux的正常现象。如前所述内核会用空闲内存做缓存。只要available内存充足free内存少完全不用担心。监控应关注available而非free。陷阱三jstack没发现死锁但应用线程全部卡住可能是遇到了“活锁”或资源池耗尽。检查数据库连接池、HTTP客户端连接池是否已满。也可以使用jstack多抓几次堆栈对比看线程状态是否有变化如果全部卡在同一个地方如等待数据库连接那很可能就是池化资源瓶颈。排查技巧保存现场在重启问题进程或机器前务必先保存现场信息这对事后复盘至关重要。一个简单的现场保存脚本可以包含以下命令#!/bin/bash DATE$(date %Y%m%d_%H%M%S) DIR/tmp/investigation_$DATE mkdir -p $DIR cd $DIR top -b -n 1 top.log vmstat 1 10 vmstat.log iostat -xz 1 10 iostat.log ps aux ps.log netstat -antp netstat.log # 或 ss -antp ss.log jstack PID jstack.log 21 # 如果是Java应用 # ... 其他必要命令 tar -czf ../investigation_$DATE.tar.gz .这个压缩包就是事故现场的“快照”包含了问题发生时最关键的系统状态。性能优化和问题排查是一个永无止境的学习过程。工具是死的思路是活的。我最深的体会是不要死记硬背命令参数而是要理解每个工具输出的每一个字段代表什么物理意义以及它们之间如何相互印证。当你拿到一个性能问题能像侦探一样从监控大盘的异常指标线索出发熟练地运用USE/RED方法论组织你的调查方向并精准地选取top-pidstat-jstack/perf这样的工具链层层深入最终定位到一行代码或一个配置时那种成就感是无与伦比的。这套工具箱和思考方式希望能成为你在Linux世界里解决性能谜题的可靠伙伴。
