标签频道
内存管理
该标签下的文章、提问与讨论帖。
现象或背景 - 集群：K8s 1.28.9，cgroup v2，containerd 1.7.13，内核 5.15 - 服务：Go 1.22 无状态 API（订单查询），Pod spec "memory.request=2Gi / memo
【背景】 - K8s 1.28.9 集群，cgroup v2，节点规格 32C256G - 核心 Java 17 服务（Spring Boot 3.2），12 个 Pod，每个 Pod memory request=4Gi / limit=
背景 我做了 8 年运维，OOM Killer 是生产 Linux 服务器上最让人头疼的高频告警之一。目前团队排查方式基本是 "dmesg | grep -i oom" + "journalctl -k" 人肉翻日志，效率低、容易漏根因，新
【背景】 我干了三年嵌入式，对「资源边界」这件事天然敏感——RAM 就那么多，越界就是 HardFault。转做容器化运维后，发现 K8s 里资源边界这件事，团队间的做法分歧极大，而且没有人能给出一个「标准答案」。 具体场景：一个 12 节
【背景】 - K8s 1.28.9 集群，cgroup v2，节点规格 32C256G - 核心 Java 17 服务（Spring Boot 3.2），12 个 Pod，每个 Pod memory request=4Gi / limit=
背景 10 节点（16C64G，Kubernetes 1.28.9 + containerd 1.7.13，内核 5.15.0-91，cgroup v2）在线集群，跑两类服务：Go 1.22 无状态 API（订单查询）和 Java 17 /
背景 - K8s 1.28.9 + cgroup v2，Go 1.22 无状态 API 服务（订单查询），Pod spec "memory.request=2Gi / memory.limit=2Gi"（request=limit 避免 Q
背景 - 集群：K8s 1.28.9，cgroup v2，containerd 1.7.13，内核 5.15 - 服务：Go 1.22 无状态 API（订单查询），Pod spec "memory.request=2Gi / memory.
一、现象与背景 一台 PostgreSQL 15.4 实例（32C 128G，NVMe SSD 2TB，"shared_buffers=48GB"），承载两个业务： - 在线查询服务：HikariCP "maximumPoolSize=64
«结论先行："free -h" 显示还有 40G 空闲、机器也没 OOM，但 JVM / Python / Node 进程就是起不来、报 "Cannot allocate memory (ENOMEM)"——十有八九不是内存真不够，而是内核
背景 最近给一个 200+ Pod 的 K8s 集群做容量审计，发现一个很有意思的现象：同一个团队的 Java 服务，A 团队 limit=requests，B 团队 limit=2×requests，C 团队干脆不写 limit 只写 r
文
标题
摘要