fix(deploy): give apihost a realistic memory request

The 80% memory target was measured against a 256Mi request while the process
actually sits between 114Mi and 700Mi (oxocache L1 plus the 96MB PDF page
budget), so average utilization never dropped below the target and the HPA
pinned apihost at maxReplicas=6 while CPU idled at 0-2%.

Request 512Mi (limit unchanged at 1Gi) puts the target at ~410Mi, which is
the "this pod is genuinely loaded" line it was meant to be: right after the
rollout the metric reads 18% instead of >100%, and the fleet can scale back
down to minReplicas once the load is gone.

ZhenYi committed 1 month ago

parent 6113ee6 commit f8f592e Browse files

deploy/values/prod.yaml +6 −0 View

@@ -109,6 +109,12 @@

109109 # apihost 自动扩缩：CPU 是主指标，内存负责兜住 L1 缓存膨胀（limit 1Gi / request 256Mi）

110110 # min 2 与 PDB minAvailable 1 相容；max 6 = 1.5 核请求量，节点池足够。

111111apihost:

112 # 进程常驻内存实测 114Mi ~ 700Mi（oxocache L1 + PDF 页缓存），256Mi 的 request

113 # 让内存指标长期 >80%，HPA 因此被钉死在 maxReplicas。把 request 抬到实测中位数

114 # 之上后，80%（约 410Mi）才真的是「这个 pod 忙」的信号；limit 仍是 1Gi。

115 resources:

116 requests: { cpu: 250m, memory: 512Mi }

117 limits: { memory: 1Gi }

112118 autoscaling:

113119 enabled: true

114120 minReplicas: 2