首次上线的时候怎么定？靠压力测试？后续应用不停上线、甚至改配置可能会导致内存、cpu 的变化，如何持续迭代更新每个应用的 request 和 limit 呢？
 |
1
mooyo 2 天前
我印象中 request 还不能太小，忘了啥原因。
我们之前是所有 pod 固定的 request 和 limit （ request:2 limit:8 ），靠 pod 数量来伸缩，极个别特殊的 pod 手动调整。 |
 |
3
vkillwucy 2 天前 via Android
用不明白，就设置一样😁
|
 |
4
ZSeptember 2 天前
初始化一般业务评估就行，业务对自己的业务量应该有点数。
然后监控使用率，使用率太低，推进调低，使用率高，推荐提高。 |
 |
5
xavi818 2 天前  1
用 vpa 给你推荐下资源配置
|
 |
6
zhoudaiyu OP @xavi818 这个可以，但是第一次上线的时候好像推荐不出来吧
@vkillwucy 我们就是差不多都一样的，但是其实资源使用率差的挺多的 @ZSeptember 业务根本不懂这些，也不管，所以都得靠我们运维推，太难了 |
 |
7
stormtrooperx5 2 天前
很难搞，我们还因为 req 设置不合理出过线上故障
|
 |
8
billzhuang 2 天前 via iPhone
设置好 hpa 和 autoscaler
|
 |
9
xiaogu2014 2 天前
刚上线的时候会设置一个大概的 request 和 limit 。（自己决定哦。同时得配合 hpa ）
后续有一个 tuned request 和 limit 会附加上去。（这块应该是 infra 组来做的。来根据历史来帮你调整。能节省不少资源） 同时后续应用不停上线 cpu 也不会急剧上升。👆会自己帮你调整。当然你得设置好 hpa 来应对突发情况。 |
 |
10
7h0m25 1 天前
之前维护的比较多的是 Java 项目，Java 项目很多启动的时候会给你一个默认的资源需求参数，稍稍加大一点设置为 request 就好。Limit 的就得看你自己的经验和在测试环境里的压测评估结果来预估了。
之前公司的开发都是外包给三方团队的，代码很垃圾，最夸张的一个 Java 项目启动要四分半才能起来。一开始是让那些开发自己估（毕竟开发才是最清楚自己写的是一堆什么 shit ），结果估了几次给出的参数都是非常离谱的。 |
 |
11
NaVient 1 天前
这个在每个公司都是难点，可以一开始设置大一些，后续看监控数据再慢慢缩
|
 |
12
IndexOutOfBounds 1 天前
limit 一般是 Request 的两倍到四倍，太高超卖谁也用不高
Request 大概估个范围 + HPA |
|
13
IndexOutOfBounds 1 天前
HPA 还可以基于自定义指标，比如 QPS ，这样后续维护只需要关注每个请求的资源变化就可以了
|
 |
14
westlife66 12 小时 22 分钟前 via Android
Limit 一般可不用设置。设置了会影响瞬时处理器资源分配。特别是对于有低延迟需求的服务来说，会极大拉长 p95 以上的延迟。这方面有很多文档在讲解，可以谷歌看看
Request 一般是跑压力测试综合性能指标评估下单 pod 负载。找到一个合理的，适合扩容缩容的资源。 |
|
15
westlife66 12 小时 14 分钟前 via Android
刚说的是 cpu 的配置，如果有个别服务处理器资源占用比较厉害的，可能影响整个集群其它服务的，还是需要限制，具体问题具体分析。
至于内存配置看情况，limit 一定要设置，而且多数情况 Request = Limit ，这样能保证内存分配可用性。具体多少还是压力测试来 |
Select Language