go程序在k8s中oom killed需优先调优gc和gomaxprocs：显式设置gomaxprocs、降低gc频率（如setgcpercent或setmemorylimit）、启用godebug=madvdontneed=1，并合理配置requests/limits。
Go程序在K8s里OOM Killed？别急着加内存limit，先看GC和GOMAXPROCS
容器里OOMKilled不是内存设小了就完事——Go运行时对cgroup内存限制不敏感，堆涨到接近limits.memory时，一次大分配或GC未及时触发，内核直接杀进程。更麻烦的是：docker run --cpus=2不会自动同步给GOMAXPROCS，K8s里也一样。
- 必须显式设置
GOMAXPROCS：建议用runtime.GOMAXPROCS(int(numCPUs))读取resources.limits.cpu（通过Downward API注入环境变量如MY_CPU_LIMIT），再转换为整数 - 调低GC触发频率：默认
debug.SetGCPercent(100)太激进，压测后若稳定堆在300Mi，可设debug.SetGCPercent(50)或更稳妥的debug.SetMemoryLimit(400 * 1024 * 1024)（Go 1.19+） - 启用
GODEBUG=madvdontneed=1：让Go归还内存时用MADV_DONTNEED而非MADV_FREE，避免内核误判“内存还在用”，降低OOM概率
K8s中resources.requests和limits怎么配才不浪费又不翻车
设requests: cpu: "100m", memory: "128Mi"看着安全，但实际可能让Pod永远卡在Pending，或上线后CPU使用率长期低于10%，白占资源；设太高又导致调度器挑不出节点，或OOM前毫无预警。
-
requests是调度门槛，必须反映**稳态最低需求**：比如压测下Golang HTTP服务平均消耗200m CPU / 150Mi memory，requests可设为250m / 200Mi，留点缓冲但不过度保守 -
limits是硬顶，要略高于峰值但留余地：内存limits建议不超过requests × 2.5（如200Mi → 512Mi），CPUlimits可稍宽松（如500m），因CPU是弹性资源 - 切忌只设
limits不设requests：K8s会自动把requests拉平到limits值，等于变相锁死调度策略
为什么你的Golang服务在容器里响应延迟突增？检查http.Server和net参数
本地跑得好好的，一上K8s就accept queue full、TLS握手超时、keep-alive连接被秒断——问题不在代码逻辑，而在容器网络栈和Go默认配置的错配。
-
http.Server必须显式设ReadTimeout、WriteTimeout（如5s），否则慢客户端会永久占住goroutine -
IdleTimeout建议30–60s，太短导致客户端连接池反复重建，太长又拖慢连接回收 - 监听socket backlog默认太小：需用
net.ListenConfig{Control: func(fd uintptr) { syscall.SetsockoptInt32(int(fd), syscall.SOL_SOCKET, syscall.SO_BACKLOG, 4096) }}手动加大 - 别依赖
net.core.somaxconn宿主机值——CNI插件（如Calico、Cilium）常自带更严的队列限制，得结合ss -lnt实测
想自动调优？HPA和VPA不是万能解药，得看Golang应用类型
HPA按CPU或内存扩缩容，对Golang这种轻量级、高并发服务容易误判：GC暂停期CPU飙高、或内存缓慢增长未达阈值，都可能导致扩缩混乱；VPA虽能调requests，但重启Pod有中断风险。
立即学习“go语言免费学习笔记（深入）”；
- HTTP类Golang服务优先用**自定义指标HPA**（如QPS、P95延迟），比CPU更贴近业务真实压力
- VPA适合非核心服务或测试环境，生产环境慎用
Auto模式；若要用，配合updateMode: Off先观察推荐值，再人工灰度调整 - 计算密集型服务（如图像转码）可结合
nodeSelector打标+taints/tolerations隔离专用节点，比靠HPA硬扩更稳
最常被忽略的一点：Golang应用的资源行为高度依赖实际负载特征，没有放之四海而皆准的配额模板。压测数据、cAdvisor实时指标、以及kubectl top pods的长期趋势，比任何文档里的“推荐值”都管用。
