是这样我们生产环境 Java 业务主要跑在 K8s 上，一台 node 24 核 48 线程的机器大概跑 50 个左右的 Pod ，平时 cpu 利用率在 60 到 70 ，但是负载有时候很高(100 到 150)，领导认为负载比较高，要优化，但是我看 CPU 是够的，并且服务也没有变慢。用 vmstat 定位了一下负载高仅为 R 状态线程多，并不是 D 状态线程多，但是不是很好找到到底是哪个业务 Pod 导致的这个问题。所以请问一下:1 负载是不是一个判断资源利用率的强指标 2 如果是怎么能找到到底是谁导致的负载高？ btw:内核是 3.10 和 4.19 两种
This topic created in 36 days ago, the information mentioned may be changed or developed.
 |
1
Lax Aug 24
第一份工作的领导，教我登上服务器的第一个命令，就是 w
负载偶尔是核心数 2~3 倍一般没问题，关键是看监控中的业务指标，比如服务延迟有没有恶化。类比学校食堂，负载就是队列长度，能在合理开饭时间内让全部人吃完就没问题。 总之先上监控吧，找到具体 pod, 然后去 jstat/jstack/jmap 。不过现在都是 AI 调试了，不要再搞这些命令行 |
 |
2
ntdll Aug 24
我这的领导逻辑正好相反。如果负载长期低于 50%，会说负载太低，说明机器资源被浪费了，需要减配，顺便可以缩减成本。
要申请增配得负载长期/峰值持续维持在 90%以上。 |
 |
3
ttkanni Aug 24
1 负载是不是一个判断资源利用率的强指标？
是，但也看业务类型。我们业务对时延敏感，一般单节点 POD 分配的 CPU 配额最高到节点 CPU 资源（超线程）的 150%，同时会观察节点 P90 水位线。CPU 比内存更具有瞬时性，一时 100%说明不了问题，但要是周期性持续 100%也要注意。 2 如果是怎么能找到到底是谁导致的负载高？ 接 Prometheus 监控，在监控内按照 Node 去找资源开销最大的 POD 。现在企业级的 Prometheus OEM 产品基本可以对接 AI ，一句话让 AI 去检索。至于 POD 内是什么导致 CPU/MEM 持续高负载得看业务日志了，如果接了 APM 这块就容易些。 |
Select Language