request 和 limit 不能设成一样，因为调度器只依据 request 分配节点，limit 仅在 oom 或 cpu 节流时生效；两者相等会消除弹性缓冲，导致内存突发时直接被 oomkilled，且无法利用节点空闲资源。
为什么 request 和 limit 不能设成一样？
因为 Kubernetes 调度器只看 request 分配节点，而 limit 只在 OOM 或 CPU 节流时起作用。两者相等看似“稳妥”，实则让 Pod 失去弹性缓冲——内存突发时直接被 OOMKilled，且无法利用节点空闲资源。
常见错误现象：Pod 频繁重启，kubectl describe pod 显示 Reason: OOMKilled，但 top 查看容器内 RSS 常年低于 limit。
-
request应反映应用稳定期的**最低可用内存需求**（比如 GC 后的常驻堆 + OS 缓存） -
limit应略高于**观测到的最大 RSS 峰值**（建议加 15%~25%，不是翻倍） - Golang 的 GC 周期依赖堆大小，
limit过高会导致 GC 触发延迟，反而推高 RSS；过低则频繁触发 GC 并可能 OOM
如何用 pprof 和 metrics-server 定出真实内存基线？
别靠估算或本地 go run 看 runtime.ReadMemStats —— K8s 环境下 runtime 行为受 cgroup 限制，本地数据无效。
使用场景：上线前压测阶段、线上灰度流量观察期。
立即学习“go语言免费学习笔记（深入）”；
- 在服务中暴露
/debug/pprof/heap，用curl http://pod-ip:port/debug/pprof/heap?gc=1获取实时堆快照（注意：生产环境慎开，建议仅限调试侧边车或临时开启） - 部署
metrics-server后，运行kubectl top pods --containers，重点看MEMORY(%)列和历史趋势（至少 24 小时），取 P95 RSS 值作为limit下限参考 - 对比
container_memory_working_set_bytes（cgroup working set）和container_memory_rss：前者含 page cache，后者更贴近 Go 实际堆占用；优先以rss为准
Golang 特有的坑：GOMEMLIMIT 与 limit 的冲突
Go 1.19+ 支持 GOMEMLIMIT，它会主动限制 Go 堆增长，避免触发 Linux OOM Killer。但如果设得比容器 limit 还高，就失去意义；设得太低，又会引发无谓 GC。
参数差异：GOMEMLIMIT 是 Go runtime 内部阈值（默认为物理内存的 90%），而 limit 是 cgroup.memory.max（Linux 层硬限）。
- 推荐设置：
GOMEMLIMIT = 0.8 * container limit（例如 limit=1Gi → GOMEMLIMIT=858993459） - 必须用字节数设置，不支持
1G或1Gi字符串写法，否则 Go 忽略该变量 - 若未设
GOMEMLIMIT，Go 会按limit自动推导，但推导逻辑在 cgroup v1/v2 下不同，容易误判——所以显式设置更稳
Request/Limit 比例没标准答案，但有安全区间
比例本身不重要，关键看是否匹配实际负载曲线。强行套用 “2:1” 或 “3:1” 在 Golang 项目里大概率翻车。
性能影响：request 过低 → 调度器把多个高内存 Pod 打包进同一节点 → 彼此争抢 → RSS 波动放大；limit 过高 → Kubelet 不干预，但 Node 内存耗尽后批量驱逐，雪崩风险上升。
- 典型健康比例：request:limit ≈ 0.6:1 ~ 0.75:1（例如 request=600Mi, limit=1Gi）
- 低流量后台任务（如 cron job）可放宽至 0.4:1，但需确认 GC 周期不受影响
- 高频 HTTP 服务（尤其带大 payload 解析）建议不低于 0.7:1，并配合
GOMEMLIMIT锁定堆上限
最易被忽略的一点：Golang 的 runtime.MemStats.Sys 包含 mmap 内存，这部分不受 GOMEMLIMIT 管控，却会计入 cgroup RSS —— 如果用了 unsafe 或第三方库（如某些 SQLite 绑定），得单独监控 container_memory_mapped_file。
