在容器内用 top 查看进程级资源消耗是定位高负载根源最有效的方式之一，可精准反映容器内部真实运行状态，尤其适合排查 java、node.js 或 python 进程的 cpu/内存持续占满问题。
直接在容器内用 top 查看进程级资源消耗，是定位高负载根源最有效的方式之一。它不依赖外部工具，能精准反映容器内部真实运行状态，尤其适合排查 CPU 或内存被某个 Java 进程、Node.js 服务或 Python 脚本持续占满的情况。
进入容器后启动 top 并按需排序
先通过 docker exec -it bash 进入容器（若基础镜像不含 bash，可用 sh 替代）。确保已安装 procps（Ubuntu/Debian 执行 apt-get install -y procps；Alpine 用 apk add procps）。
运行 top 后，默认按 CPU 使用率从高到低排序。如需切换排序维度，可直接按键操作：
- P：按 CPU 使用率（%CPU）降序（默认）
- M：按物理内存占用（%MEM）降序
- T：按运行时间（TIME+）降序
- N：按 PID 升序（便于快速定位特定进程）
用命令行参数预设排序方式
避免进入交互界面再按键，可直接用参数启动 top：
-
top -o %CPU—— 按 CPU 占用率排序（默认行为） -
top -o %MEM—— 按内存占用百分比排序 -
top -o RES—— 按实际物理内存（KB）数值排序，更直观反映内存“吃紧”程度 -
top -b -n 1 -o %CPU | head -20—— 一次性输出前 20 行（适合脚本采集或日志记录）
结合 docker top 快速关联宿主机 PID
宿主机上运行 docker top ，可看到容器内所有进程在宿主机上的真实 PID。再用 ps -p <pid> -o pid,ppid,comm,%cpu,%mem,rss,vsz,time,user</pid> 查看详细资源指标，与 top 输出交叉验证。
例如发现容器内某 Java 进程 RSS 达 1.2GB，但 %MEM 显示仅 8%，说明容器内存限制（--memory）可能设得偏小，触发了 OOM 或频繁 GC —— 此时需检查 docker inspect 中的 HostConfig.Memory 设置。
注意 top 在容器中的显示局限
top 默认显示的是容器视角的资源视图，其总内存、总 CPU 是宿主机的全量值，而非容器限制值。这容易造成误判。例如一个限制为 512MB 的容器，top 显示 “Mem: 16G total”，但实际可用远小于此。
更准确的方式是配合 docker stats 查看实时限制内用量（含 %MEM 基于限制值计算），或读取 cgroup 文件：
- CPU 使用率：
cat /sys/fs/cgroup/cpu,cpuacct/docker//cpuacct.usage_percpu - 内存当前用量：
cat /sys/fs/cgroup/memory/docker//memory.usage_in_bytes - 内存限制值：
cat /sys/fs/cgroup/memory/docker//memory.limit_in_bytes
