高并发下性能瓶颈需逐级下沉定位：先区分“卡”（延迟升高）还是“挂”（不可用），再结合CPU+wa、CPU+cs、内存+Swap等异常组合交叉验证，最后深入线程级和系统限制排查。
高并发下服务器性能瓶颈不能靠猜，得按资源层逐级下沉定位。关键不是“哪个命令最炫”，而是“先问清楚问题在哪儿”。
先分清是“卡”还是“挂”
服务响应变慢（比如接口从200ms拖到2秒），和完全不可用（502/连接拒绝/进程消失），排查路径完全不同。
- 如果只是延迟升高、部分请求超时，重点查CPU调度、线程阻塞、锁竞争、GC停顿、数据库慢查询；
- 如果服务直接起不来、端口监听失败、进程反复重启，优先查端口冲突、文件句柄耗尽（Too many open files）、内存OOM杀进程、配置加载失败；
- 如果现象是间歇性抖动（每分钟卡几秒），要结合时间线看是否跟定时任务、日志轮转、备份脚本、监控采集周期重合。
盯紧三类核心资源的“异常组合”
高并发场景中，单看一个指标容易误判。必须交叉验证：
- CPU高 + wa（iowait）高：不是CPU真忙，是进程在等磁盘IO，实际瓶颈在磁盘或存储后端（如NFS挂载卡住、SSD写满、RAID降级）；
- CPU高 + cs（上下文切换）极高（>10万/秒）：大概率是线程数过多、锁粒度太细、或频繁系统调用（如大量小包recv/send）；
- 内存充足但Swap活跃 + si/so不为0：说明内核在做页面换入换出，即使free -h显示还有空闲内存，也可能是内核页缓存被过度回收，或应用用了mmap大文件触发了交换；
- netstat/ss显示大量TIME_WAIT但业务连接失败：不是连接数不够，而是端口耗尽（65535上限），需确认是否短连接高频复用、是否开了tcp_tw_reuse、是否客户端没正确关闭连接。
快速定位到具体进程和线程
别只停留在top看进程，高并发问题往往藏在线程级：
- 用 pidstat -t -p PID 1 查指定进程各线程的CPU占用，找出真正吃资源的TID；
- TID转十六进制后，用 jstack PID | grep -A 10 '0x...' （Java）或 perf top -p PID（C/C++/Go）看热点函数；
- 用 strace -p PID -e trace=sendto,recvfrom,write,read -s 64 看是否卡在某个系统调用上；
- 用 lsof -p PID | wc -l 和 cat /proc/PID/limits 对比，确认是否接近文件描述符上限。
别忘了检查系统级软限制
很多高并发问题根本不是代码或硬件问题，而是被默认参数卡死：
- ulimit -n 默认常为1024，Web服务器或代理（如Nginx、Envoy）很容易打满；
- /proc/sys/net/core/somaxconn 决定listen队列长度，过小会导致SYN包被丢弃；
- /proc/sys/net/ipv4/tcp_max_syn_backlog 配合somaxconn控制半连接队列；
- /proc/sys/vm/swappiness 设为1（非0）可大幅降低Swap倾向，避免内存压力下误触发交换。
