-
我给容器里的 Java 应用明明设了 2GB 的内存上限、也没配多大的堆,可它一加压就被 OOMKilled 反复重启,我对着监控看 JVM 堆用量百思不得其解,最后才搞懂这个老版本 JVM 根本不知道自己被关在了 2GB 的容器里它按宿主机那 64GB 内存算了个十几 GB 的最大堆的深度复盘
我把 Java 服务部署到 K8s、给容器设了 limits.memory: 2Gi,想着 2GB 够它跑、启动 JVM 也没特意配 -Xmx。低负载正常,可流量一上来负载一加压 Pod 就被 OOMKilled、重启、再被杀陷入 CrashLoop。我以为是堆不够或内存泄漏,可监控里 JVM 堆使用量还没涨多高就被杀;又怀疑 limit 设小了,可这服务物理机上撑死用一两 GB。直到进容器执行 …- 4
- 0
-
我给容器设了 CPU limit,监控上 CPU 用量明明远没到上限,服务却偶发严重的延迟尖刺和卡顿,查了半天才发现它一直在被悄悄节流:一次容器 CPU limit 与 CFS 配额节流的深度复盘
我的服务跑在 K8s 上,设了 limits.cpu: "1"。线上偶发严重延迟尖刺(P99 从 50ms 飙到几百毫秒甚至超时),可 CPU 监控显示用量只有 50%~60%、远没到上限,内存正常、GC 也不频繁,往网络/下游/GC 查了好几天都没结果。直到看了平时从不关注的 container_cpu_cfs_throttled 指标才恍然大悟:CPU limit 不是稳定…- 0
- 0
-
我那个每天凌晨两点的定时任务,上了容器后变成了上午十点跑,日志时间也全差了八小时,只因容器里的时区是 UTC:一次容器时区不一致的深度复盘
我有个定时任务配的是每天凌晨 2 点执行(挑业务低谷),本地和物理机一直好好的。上了容器(K8s)后运维发现它居然在上午 10 点左右跑(正好业务高峰),而且容器日志时间戳全比实际慢了 8 小时。进容器 date 一看才明白:多数基础镜像默认时区是 UTC,不是东八区——我配的凌晨 2 点被容器当成了 UTC 02:00 也就是北京时间上午 10 点,now()/日志取的也是 UTC 时间慢 8 …- 0
- 0
-
我的 Java 服务在容器里跑着跑着就被干掉重启,kubectl 显示 OOMKilled,可服务器明明有几十 G 内存,排查发现是 JVM 根本不知道自己被关在了一个小盒子里的深度复盘
我的 Java 服务跑在 K8s 里、给容器设了 memory limit 512Mi,可它跑着跑着就被杀掉重启,kubectl describe pod 写着 OOMKilled,而宿主机明明有几十 G 内存,JVM 自己也没抛 OutOfMemoryError。查到底才明白:JVM 没感知到容器的内存限制——它启动时按看到的机器总内存(宿主机几十 G,不是容器 cgroup 限制的 512Mi…- 0
- 0
-
我给容器设了 2G 内存上限,Java 服务却反复被 OOMKilled 重启,JVM 日志里还说自己堆远没满,我对着容器里的 JVM 不感知 cgroup 内存限制按宿主机内存设堆这个坑排查了大半天的复盘
一个让我对容器里的程序到底看到多少内存彻底搞明白的 DevOps 坑,抓狂在一个矛盾现象:容器被系统以内存超限 OOMKilled 杀掉,可 JVM 自己的监控却一脸无辜说堆还远没满,一边喊内存爆了一边说还多着呢。Java 服务部署 K8s 容器设内存上限 2Gi,Pod 反复重启 Reason=OOMKilled、Exit137、Restart Count 飙升;进容器看 JVM 说堆用得好好的…- 0
- 0
-
我的服务一上容器,日志时间和入库时间全慢了 8 小时,定时任务也在半夜诡异触发,我对着这个差了 8 小时的时区问题排查了大半天的复盘
我的服务本地一切正常,一打包成容器上线,所有时间就比北京时间慢了整整 8 小时:日志下午3点的事记成上午7点、入库 created_at 全差8小时、本该凌晨2点的定时任务在上午10点诡异触发。深挖才懂:容器基础镜像默认是 UTC 时区,我没配时区,而本地开发机是东八区,所以本地碰巧对、一上默认 UTC 的容器就差8小时——程序取系统当前时间得到的是 UTC、比北京少8小时,所有依赖系统当前时间的…- 0
- 0
-
我的 Java 服务一上 K8s 就莫名其妙地被反复重启、退出码永远是 137,我对着 OOMKilled 这个状态和容器内存限制排查了大半天才搞懂的惨痛经历
我的 Java 服务在虚拟机上稳如老狗,一上 K8s 就反复重启,kubectl describe 显示 Reason: OOMKilled、Exit Code: 137。我给容器配了 4G limit、虚拟机上 4G 也够用,怎么会内存不足?深挖才懂:JVM 在容器里"看不见"cgroup 的内存 limit——容器 limit 是 4G 但节点宿主机有 64G,我没设 -X…- 0
- 0
-
容器设了 2GB 内存上限服务却反复被 OOMKilled、可 JVM 堆明明没满:JVM 不感知容器限制按宿主机算堆撑爆容器的避坑复盘
这是我们把一个老 Java 服务上容器时踩的第一个也是最懵的一个坑。我们把这个服务打成镜像部署到 K8s 给它的容器设了一个内存上限 2GB,我们估摸着这个服务平时也就用几百兆内存 2GB 绰绰有余了。可服务一启动跑不了多久就被 K8s 给 OOMKilled 因内存超限被杀了,杀了之后自动重启重启完跑一会又被杀如此反复陷入了 CrashLoopBackOff 崩溃重启循环根本起不来。我特别纳闷这…- 6
- 0
-
宿主机内存够却被 OOMKilled:容器 JVM 内存避坑
我们把一个 Java 服务容器化上了 K8s,给 Pod 配了 2GB 内存上限,本以为足够宽裕。可上线后容器三天两头重启,Pod 状态写得明明白白:OOMKilled、退出码 137。最费解的是这台宿主机有 64GB 内存空闲得很,进容器用 top、free 看显示的全是宿主机那 64GB 富得流油,可容器就是一次次以内存超限为由被处决。排查好一阵真相才浮出水面、经典得让人哭笑不得:我那个版本的…- 0
- 0
-
Docker 镜像 1.8GB 瘦身到 180MB:多阶段构建 + 层缓存实战
80 微服务 CI/CD,Java 镜像 1.8GB 构建 8min,K8s 拉取慢,节点磁盘告警。两周治理:多阶段构建 + jlink 裁剪 JRE + distroless/scratch + 层缓存指令排序 + BuildKit cache mount + Trivy 安全扫描。镜像 180MB,构建 90s,流水线提速 60%。- 4
- 0
-
Docker 多阶段构建实战:把镜像体积缩小 50 倍的工程姿势
第一次写 Dockerfile 的人,往往会得到一个 1GB+ 的镜像:把整个构建工具链、源代码、依赖、临时文件全打了进去。问题不在 Docker,在没有用多阶段构建(multi-stage build)。这是 Docker 17.05+ 引入的特性,几乎是免费的镜像瘦身术 —— 同样的功能,镜像从 1GB 缩到 50MB 不是难事。这篇文章用真实例子讲透。 先看一个反面教材 用 Go 写一个 h…- 0
- 0
容器
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×