CPU过高先看uptime/top负载，结合核心数判断；top按Shift+P找高占用进程；%sy高查系统调用，%wa高查I/O；用pidstat -u 1秒级监控。
CPU使用率过高怎么快速定位
先看整体负载，用 uptime 或 top 查看 1/5/15 分钟平均负载，结合 CPU 核心数判断是否过载（比如 4 核机器负载长期 >4 就值得查）。再进 top 按 Shift+P 排序，找 CPU 占用最高的进程。如果看到大量 %sy（系统态）偏高，可能是频繁系统调用或中断；%wa 高说明进程在等 I/O，要接着查磁盘。小技巧：用 pidstat -u 1 可以按秒级看每个进程的 CPU 使用变化，比 top 更灵敏。
内存不够用但 free 显示还有空闲怎么办
Linux 的“空闲内存”不等于“可用内存”，内核会把不用的页缓存（page cache）和 slab 缓存占着，这部分在需要时能立刻回收。真正关键的是 available 列（free -h 输出），它已估算出可立即分配的内存。如果 available 持续偏低、swap 使用量上升、pgmajfault（次缺页中断）飙升，说明内存压力真实存在。建议用 smem -s rss 查进程实际物理内存占用（RSS），比 top 的 RES 更准；再用 /proc/meminfo 看 Slab、PageTables、KernelStack 等细分占用，排查内核内存泄漏或驱动异常。
磁盘 I/O 慢，是硬盘问题还是应用写法不对
先用 iostat -x 1 看 %util 和 await：如果 %util 接近 100% 且 await 显著高于设备标称延迟（如 SATA SSD 通常 iotop 找具体读写大户。常见瓶颈点：
- 应用大量小文件随机写，没开 O_DIRECT 或没做 write buffering
- 数据库日志刷盘策略太激进（如 MySQL 的 innodb_flush_log_at_trx_commit=1）
- 文件系统挂载选项缺失 noatime、barrier=0（SSD 场景）
- RAID 卡缓存未启用或电池失效导致强制直写
验证方法：用 fio 做基准测试（如 randwrite 4k），对比应用实际 I/O 模式与磁盘极限，就能区分是硬件瓶颈还是软件低效。
网络延迟高、丢包，从哪几层开始排查
按 OSI 自下而上查：
- 物理层：用 ethtool eth0 看链路速率、双工模式、错误计数（rx_crc_errors、tx_aborted_errors）
- 网络层：用 ping -c 5 网关 判断局域网是否正常；再 mtr 目标IP 定位哪一跳延迟突增或丢包
- 传输层：用 ss -i 查 TCP 连接的重传、SACK、RTT；netstat -s | grep -i "retransmit" 看全局重传统计
- 应用层：检查是否启用了 Nagle 算法（TCP_NODELAY 未设）、连接池过小导致频繁建连、TLS 握手耗时长（可用 openssl s_time 测试）
特别注意：开启 net.ipv4.tcp_tw_reuse = 1 和调整 net.core.somaxconn 能缓解高并发短连接场景下的端口耗尽和连接拒绝问题。
