服务器瓶颈排查的关键在于将监控指标与系统命令结合，通过分析CPU、内存、磁盘I/O和网络等维度的实时数据，精准定位性能短板，避免盲目优化。
服务器瓶颈怎么排查？从指标到命令的闭环
性能瓶颈不会凭空出现,它总会在系统资源上留下痕迹，排查的第一步是建立“指标-命令”对应关系：知道看什么，才知道用什么工具看。
监控指标与排查工具对照
- CPU瓶颈：核心指标是使用率、负载（load average）和上下文切换，常用命令：top、mpstat、vmstat 1。
- 内存瓶颈：关注total、used、free、buff/cache 以及 swap 使用情况，命令：free -h、vmstat 1、smem。
- 磁盘I/O瓶颈：追踪iowait、读写延迟、队列长度，命令：iostat -x 1、iotop、sar -d。
- 网络瓶颈：测量带宽、丢包率、连接数，命令：netstat -s、ss -s、iftop、nload。
排查顺序：先全局后局部
多数情况下,瓶颈指标会集中在某个资源上，建议按CPU→内存→磁盘→网络的顺序逐层扫描，每个层面用1-2个命令快速确认，例如用top看到CPU空闲但系统负载高，说明可能卡在I/O，立刻用iostat -x 1验证。
关键点：不要只看平均值，要看峰值和波动，比如vmstat的procs列如果r长时间大于CPU核数，说明CPU饱和；b列持续非0，说明I/O阻塞。
常用命令深度解读：Linux服务器性能分析命令实战
CPU瓶颈：用top和mpstat剥开进程级消耗
top
命令能快速展示CPU使用率、负载和占用最高的进程，重点关注us（用户态）、sy（系统态）、wa（等待I/O）和id（空闲），如果wa持续超过20%，说明磁盘I/O拖累了CPU。
mpstat -P ALL 1可以查看每个CPU核的使用情况，避免单核过载导致整体性能下降，当某个核的%usr长期接近100%而其他核空闲，这是典型的单线程瓶颈，常见于旧版数据库或解释型语言应用。
内存瓶颈：free与vmstat定位泄漏与压力
free -m显示物理内存和swap使用量，如果available小于总内存的10%，说明内存紧张。vmstat 1的si和so列如果持续非0，表示系统正在频繁交换内存，这会直接拖慢所有进程。
实操：当发现swap使用量上升，先用top按%MEM排序找出占用最多的进程，再用pmap -x PID看具体内存段，确认是否存在内存泄漏。
磁盘I/O瓶颈：iostat和iotop揪出慢盘
iostat -x 1提供完整磁盘统计：%util（设备繁忙度）、await（平均I/O响应时间，毫秒）、svctm（服务时间），util超过90%且await超过几十毫秒，磁盘已经饱和。
对比场景：传统机械硬盘的await通常在10-20ms，而SSD通常低于5ms，如果业务使用SSD却出现30ms以上延迟，很大概率是队列堆积或并行度不足，此时用iotop查看具体进程的I/O读写量，定位是哪个程序在“吃磁盘”。
网络瓶颈：netstat与ss筛查连接积压
netstat -s可以看协议统计，重点关注retransmit（重传）和listen overflow，如果重传率超过0.1%，网络质量或带宽可能不足。ss -lnt查看监听队列，如果Recv-Q或Send-Q持续非0，说明应用层处理不及时。
行业共识认为：大多数性能瓶颈并非单个资源耗尽，而是多个资源之间存在“木桶效应”，例如内存不足导致swap，swap又引发磁盘I/O暴增，最终让CPU陷入等待，所以排查时需要联动分析，不能只看单一指标。
高并发场景瓶颈定位：从现象到根因
Web服务器响应慢
现象：用户请求延迟高，但服务器CPU空闲，此时应优先检查网络连接数和文件描述符，用ss -s查看连接数是否超过系统限制（ulimit -n），用lsof | wc -l确认句柄使用情况，如果连接数接近上限，调整内核参数net.core.somaxconn和net.ipv4.tcp_max_syn_backlog。
数据库查询延迟
现象：慢查询日志频繁出现，但数据库CPU利用率不高，用iostat -x 1观察磁盘await和svctm，如果两者相差很大（如await是svctm的10倍以上），说明I/O请求在排队，通常是因为磁盘每秒操作数（IOPS）达到上限，此时需要优化SQL索引或增加缓存层。
文件传输效率低
现象：scp或rsync速度远低于带宽，用iftop -i eth0看实时流量，确认带宽是否跑满，如果带宽未满但传输慢，用
iperf3测试网络吞吐量，排除物理链路问题，如果iperf显示正常，但特定应用慢，则要检查磁盘I/O或CPU加密开销，比如top中%sy高可能表示CPU忙于加密。
服务器瓶颈排查常见问题Q&A
问题：如何快速判断是CPU瓶颈还是I/O瓶颈？
看top中的%wa：如果%wa较高（通常超过30%）且%id很低，优先怀疑I/O，再用vmstat 1的b列（阻塞进程数）和iostat -x 1的%util确认，如果%wa很低但CPU负载高，并且top的us或sy高，说明瓶颈在CPU计算或系统调用。
问题：可用内存足够但系统频繁使用swap，是什么原因？
这通常是因为内核的swappiness参数设置过高（默认60），即使内存未满也会主动换出，用sysctl vm.swappiness查看，临时优化可设为10或更低，降低swap使用倾向，优先利用物理内存，长期方案应检查是否有内存分配异常，比如进程有过量的cache未释放。
问题：磁盘I/O延迟高，如何区分是硬件故障还是负载过高？
用iostat -x 1查看svctm（服务时间），如果svctm远高于正常值（如机械盘超过20ms，SSD超过5ms），说明磁盘硬件可能存在问题，如果svctm正常但%util高且await高，则是负载过高导致排队，通常需要优化I/O模式或增加磁盘并行度，换一块盘测试是最终的验证手段。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/540701.html
