容器高负载需区分内部真实负载与宿主机资源争用：先查容器内load average与nproc比值，再结合宿主机cgroup指标、进程状态及资源配额综合判断。
Linux 容器中出现高负载，不能直接套用宿主机排查逻辑——容器是隔离的运行环境，其进程、资源视图受限于 cgroups 和 namespace。但负载本质没变：load average 仍反映该容器内（或更准确地说，所属 cgroup 中）处于 R 或 D 状态的进程平均数量。排查需兼顾容器视角与宿主机视角，重点确认“高负载发生在容器内部，还是由宿主机资源争用透传导致”。
确认容器自身是否真高负载
先登录容器（如 docker exec -it <container> /bin/sh），执行：
-
uptime或cat /proc/loadavg：查看容器内看到的 load average 值 -
nproc：获取该容器被限制的 CPU 核心数（通常等于--cpus或 cgroups cpu.max 的配额） - 关键判断：若 1 分钟 load >
nproc输出值，说明容器内部确实存在排队或阻塞
注意：很多容器镜像精简，可能无 top、iostat。可临时安装（如 apk add procps iotop 或 apt-get update && apt-get install -y procps sysstat iotop），或改用宿主机工具配合容器 PID 命名空间分析。
在宿主机上定位容器内高负载根源
容器进程在宿主机上表现为普通进程，归属特定 cgroup。推荐路径：
- 找到容器主进程 PID：
docker inspect <container> | grep -i pid或podman inspect <container> | jq '.[0].State.Pid' - 查看其 cgroup 路径：
ls -l /proc/<PID>/cgroup，重点关注cpu,cpuacct和io所在的 control group（如/sys/fs/cgroup/cpu/myapp.slice/） - 检查该 cgroup 的实时负载贡献：
-
cat /sys/fs/cgroup/cpu/myapp.slice/cpu.stat→ 关注nr_throttled（被限频次数）和nr_periods -
cat /sys/fs/cgroup/cpu/myapp.slice/cpuacct.usage→ 换算成毫秒，看是否持续打满配额 -
cat /sys/fs/cgroup/io/myapp.slice/io.stat→ 若有大量rbytes=或wbytes=且rios=/wios=高，指向 I/O 密集
-
区分 CPU 密集 vs I/O 密集型容器负载
回到宿主机 top 或 htop，按 P 排序后，找到容器相关进程（USER 列常为容器用户名，COMMAND 列含容器名或入口命令）：
- 若
%CPU高（如单核 95%+）、%wa低 → 容器内应用计算密集（如 Python 循环、Java GC、FFmpeg 编码） - 若
%CPU低、%wa高（>15%）、且iotop -o -p <PID>显示该进程读写频繁 → 容器内存在同步 I/O 压力（如未缓存的日志刷盘、小文件频繁读取、数据库 fsync） - 若
ps aux | awk '$8 ~ /D/ {print}'在宿主机上筛出大量 D 状态进程，且其 PPID 属于容器 PID → 容器挂载了异常存储（如 NFS 卡死、云盘 IO 超时），进程卡在内核等待设备响应
快速抓取容器内进程行为（无需进容器）
对容器主 PID（即 init 进程 PID）直接分析：
- 查线程级 CPU：
top -Hp <PID>→ 找出最耗 CPU 的线程 TID - Java 容器：
jstack <PID> | grep "nid=0x$(printf "%x" <TID>)" -A10 - 通用系统调用追踪：
strace -tt -T -p <PID> -e trace=epoll_wait,read,write,futex,openat 2>&1 | head -n 100→ 观察是否卡在某次调用不返回 - 查打开文件与句柄：
lsof -p <PID> | wc -l→ 超过ulimit -n限制会导致连接失败、写日志失败等静默故障
不要忽略资源配额本身的干扰
容器高负载有时并非应用问题，而是 cgroups 限制造成的“假性拥堵”：
-
--cpus=0.5的容器，即使只跑一个轻量服务，也可能因 CPU 时间片不足导致队列堆积（r值升高） -
--memory=512m且应用内存接近上限时，会触发内核频繁回收 page cache，引发大量kswapd0和pgpgin/pgpgout，推高 load 并伴随sy%上升 - 检查
docker stats <container>输出中的CPUs、MEM USAGE / LIMIT、BLOCK I/O字段，比单纯看容器内top更真实反映资源约束状态
不复杂但容易忽略
