先说结论：甲骨文云 VPS Docker CPU 过高，通常是容器内应用死循环、挖矿病毒或未限制资源。优先通过 docker stats 定位，结合甲骨文控制台监控验证，必要时限制资源但需注意业务影响。
- 定位：docker stats 找出 CPU 最高的容器。
- 排查：进入容器 top 查看进程，Java 应用用 jstack 分析线程。
- 限制：docker update `--cpus` 限制配额，但可能导致服务超时。
- 验证：观察 docker stats 数值及甲骨文控制台监控图表。
1. 确认宿主机负载与甲骨文控制台监控
先在宿主机确认整体负载，同时登录甲骨文云控制台核对监控数据，排除实例本身性能波动（尤其是 ARM 免费实例）。
宿主机命令：
uptime
# 输出示例：
# 10:30:05 up 10 days, 2:00, 1 user, load average: 4.50, 3.20, 2.10若 load average 持续高于 CPU 核心数，说明负载过高。登录 甲骨文云控制台 -> 实例详情 -> 监控，查看 CPU 利用率图表。若控制台显示 CPU 已满但宿主机 top 找不到对应进程，可能是实例规格限制（如 Always Free ARM 实例共享核心性能波动）。
2. 定位高占用容器
使用 docker stats 查看实时资源占用，注意观察 CPU % 是否超过 100%（代表占用多核）。
docker stats `--no-stream`
# 输出示例：
# CONTAINER ID NAME CPU % MEM USAGE / LIMIT
# a1b2c3d4e5f6 web-app 150.00% 500MiB / 1GiB
# b2c3d4e5f6a7 redis 0.05% 10MiB / 500MiB找到 CPU % 持续居高不下的容器 ID。
3. 进入容器内部排查
进入容器内部查看具体进程。注意甲骨文 ARM 实例需使用 arm64 镜像，部分 amd64 工具可能无法运行。
docker exec -it <容器 ID> /bin/bash
# 容器内查看进程
top -H -p $(pgrep -f java) # 如果是 Java 应用
# 或普通 top 按 P 排序Java 应用线程分析：若发现 Java 进程占用高，导出线程栈分析死锁或密集计算。
# 查找 Java 进程 PID
jps -l
# 导出线程 dump
jstack -l <PID> > /tmp/thread_dump.txt排查挖矿病毒：检查是否有未知进程名、连接异常外网 IP。检查定时任务 crontab -l。
4. 设置资源限制（含风险提示）
若应用无法立即优化，可临时限制 CPU 防止拖垮宿主机。但强制限制可能导致关键业务进程超时、请求堆积甚至崩溃，生产环境慎用。
docker update `--cpus`="1.0" <容器 ID>注意命令格式，不要混用反引号。限制值建议根据实际核心数设定，如 2 核实例限制为 1.5 留有余量。
5. 验证与防御
验证生效：再次运行 docker stats，观察 CPU % 是否被限制在设定值附近。检查甲骨文控制台监控图表是否回落。
安全组配置：防止挖矿入侵，确保安全组仅开放必要端口（如 80/443），不要暴露 Docker API 端口（2375/2376）到公网。
常见坑与注意事项
- ARM 架构差异：甲骨文免费层多为 ARM 实例，部分镜像不兼容，排查工具需适配 arm64。
- 误判宿主机负载：有时是甲骨文监控 agent（osms）占用高，而非容器。
- 限制过死：CPU 限制过低会导致应用响应变慢，需根据业务 QPS 调整。