系统资源利用率不均衡典型表现为CPU核心负载不均、NUMA内存访问失衡、磁盘IO集中及进程调度倾斜；需通过mpstat、numastat、iostat和pidstat等工具逐层定位，结合绑核策略、NUMA配置、IO条带化及cgroup限频检查进行优化。
系统资源利用率不均衡，典型表现是：整体 CPU 使用率不高（比如才 40%），但某几个核心长期 95%+ 占用，其余核心空闲；或内存分配明显偏向某 NUMA 节点，导致局部缺页频繁、延迟飙升；又或者磁盘 IO 集中在某一块盘上，其他盘几乎闲置。这类问题不会立刻触发告警，却会悄悄拖慢关键服务响应，尤其在 Java、数据库、高并发中间件场景下特别隐蔽。
CPU 核心负载不均：先看分布，再查绑核
单靠 top 看总 CPU 使用率容易误判。必须展开多核视图：
- 运行 top，按 1 键显示每个逻辑 CPU 的实时占用；观察是否出现“一核满载、三核休眠”现象
- 用 mpstat -P ALL 1 每秒刷新各核的 us/sy/wa 分布，确认是不是某个核 sy（系统态）持续偏高——可能有中断集中在此核
- 检查中断绑定：cat /proc/interrupts | head -20 看软硬中断是否集中在少数 CPU 上；再查网卡队列绑核策略：ethtool -l eth0 和 cat /sys/class/net/eth0/queues/rx-*/rps_cpus
- 排查进程是否被强制绑核：taskset -cp PID 查看，常见于某些 Java 启动脚本里加了 -XX:+UseThreadPriorities 或手动设了 taskset
内存访问不均衡：警惕 NUMA 架构下的“远端内存”开销
在双路或多路服务器上，若未启用或配置不当 NUMA，进程可能跨节点申请内存，造成显著延迟：
- 用 numactl --hardware 查看节点数量、CPU 分布和内存容量；确认是否启用了 NUMA 支持
- 运行 numastat -p PID（需已知可疑进程 PID），重点看 numa_hit 和 numa_foreign 比值——foreign 高说明频繁访问远端节点内存
- 对 Java 进程，检查是否加了 -XX:+UseNUMA；对 MySQL，确认 innodb_numa_interleave=ON 是否生效
- 临时验证：用 numactl --membind=0 --cpunodebind=0 your_command 强制绑定单节点，对比性能变化
磁盘 IO 分配失衡：不止看 util，要看队列与服务时间
一块盘 %util 到 98%，另一块才 10%，不代表后者没压力——可能前者是随机小 IO，后者是大块顺序写，吞吐已饱和：
- 用 iostat -x 1 观察 r_await/w_await（平均等待毫秒）、svctm（平均服务时间）和 %util；若某盘 await 高而 util 不高，说明请求排队严重
- 结合 iotop -o 找出只往特定盘写数据的进程（如日志轮转脚本、备份任务、单点挂载的 NFS）
- 检查 LVM 或 RAID 层是否做了条带化（striping）；裸设备直连时，确认应用层有没有做多路径或分库分表打散 IO
- 查看挂载选项：mount | grep "ext4"，留意是否有 noatime, nobarrier 等影响 IO 分布的参数
进程与线程调度倾斜：上下文切换不是越少越好
看似“负载低”，但 cs（context switch）每秒超 5 万次，往往意味着调度器在多个轻量级线程间反复横跳，消耗大量 CPU 周期：
- 用 vmstat 1 看 cs 列趋势；同时关注 r（运行队列长度）是否稳定在 1~2，但 cs 却异常高——这是线程争抢 CPU 时间片的信号
- 用 pidstat -w 1 查看各进程的 cswch/s（自愿切换）和 ncswch/s（非自愿切换）；ncswch 高通常说明线程被抢占或锁竞争激烈
- 对 Java 应用，jstat -gc PID 看 GC 频率；频繁 Young GC 会引发大量线程暂停和重调度
- 检查是否启用了 cpu.cfs_quota_us 等 cgroup 限频策略，导致进程被周期性 throttled，进而引发调度抖动
