案例分享-full gc导致k8s pod重启

最新推荐文章于 2024-05-11 17:08:11 发布

原创

最新推荐文章于 2024-05-11 17:08:11 发布 · 317 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#kubernetes #容器 #云原生

本文分享了一次由于Full GC频繁触发导致Kubernetes Pod重启的案例。通过排查，发现是大量数据导出到Excel时引发的问题，包括无分页查询、Apache POI性能问题、导出无限流和同步导出。解决方案包括查询分页、更换性能更好的导出工具（如EasyExcel）以及实现异步导出，实施后有效减少了Full GC引发的Pod重启问题。

在之前的记一次k8s pod频繁重启的优化之旅中分享过对于pod频繁重启的一些案例，最近又遇到一例，继续分享出来希望能给大家带来些许收获。

问题现象

报警群里突然显示某pod频繁重启，我随即上去查看日志，主要分这么几步：

1.查看pod重启的原因，kubectl descirbe pod

Last State:     Terminated
      Reason:       Error
      Exit Code:    137

上面的Reason：Error太宽泛了，不能直观的知道原因，Exit code：137一般表示程序被 SIGKILL 中断信号杀死，异常原因可能为：

https://cloud.tencent.com/document/product/457/42945

首先排除OOMKilled情况，剩余的就是livenessProbe(存活检查)失败。

2.查看pod事件，kubectl descirbe pod，重点关注输出的Events部分

Warning  Unhealthy  2m56s (x8 over 7m16s)   kubelet            Liveness probe failed: Get http://10.244.11.136:8080/jc_actuator_1/health: net

最低0.47元/天解锁文章

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

「已注销」

关注关注

1
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

记一次k8s pod频繁重启的优化之旅

l081499的博客

09-24

2714

1.背景最近有运维反馈某个微服务频繁重启，客户映像特别不好，需要我们尽快看一下。听他说完我立马到监控平台去看这个服务的运行情况，确实重启了很多次。对于技术人员来说，这既是压力也是动力，大多数时候我们都是沉浸在单调的业务开发中，对自我的提升有限，久而久之可能会陷入一种舒适区，遇到这种救火案例一时间会有点无所适从，但是没关系，毕竟… “我只是收了火，但没有熄炉”，借用电影中的一句话表达一下此时的心情。 2.初看日志我当即就看这个服务的运行日志，里面有大量的oom异常，如下： org.springframe

一次频繁Full GC的排查过程

热门推荐

沈鸿斌的博客

10-03

1万+

问题描述最近公司的线上监控系统给我推送了一些kafka lag持续增长的消息，我上生产环境去看了相应的consumer的情况，发现几台机器虽然还在处理消息，但是速度明显慢了很多。问题猜测与验证我猜测是JVM频繁做Full GC，导致进程也跟着频繁卡顿，处理消息的速度自然就慢了。为了验证这个想法，先用jstat看看内存使用情况： jstat -gcutil 1 1000 #1是进程号结果如我所

参与评论您还未登录，请先登录后发表或查看评论

uf4b-app频繁Full GC排查

weixin_45111739的博客

10-07

321

G1最大的特点就是非常重视高吞吐量与软实时性(soft real-time，稍微超出几次最后期限也没有什么问题的系统，例如网络银行系统)的最佳平衡，它允许用户来设定期望最大暂停时间(Stop the word)。G1垃圾收集器可以预测下次 GC 会导致应用程序暂停多长时间。根据预测出的结果，G1会通过延迟执行GC、拆分 GC 目标对象等手段来尽量满足用户设置的期望最大暂停时间，默认的暂停目标是 200ms。当然，你想让GC时暂停多久，它就能尽量的满足你。终于完成这一篇排查分析的文章。

Kubernetes 健康检查之 livenessProbe/readinessProbe

小楼一夜听春雨，深巷明朝卖杏花

09-24

1万+

Kubernetes三种探针 k8s支持存活livenessProbe和就绪readinessProbe两种探针，两种探针都支持以下三种方式一、exec 通过执行shell命令的方式，判断退出状态码是否是0，示例： exec: command: - cat - /tmp/healthy 二、tcp 通过TCP请求的方式，是否能建立tcp连接，示例： tcpSocket: port: 808.....

【华为OD统一考试B卷 | 200分】服务失效判断（C++ Java JavaScript Python）

m0_57042151的博客

09-16

557

2023年5月份，华为官方已经将的 2022/0223Q(1/2/3/4)统一修改为OD统一考试（A卷）和OD统一考试（B卷）。你收到的链接上面会标注A卷还是B卷。请注意：根据反馈，目前大部分收到的都是B卷。但是仍有概率抽到A卷。A卷对应之前2023的新题库（2022Q4 20223Q1）B卷对应之前专栏的20022部分考题以及新出的题目。

kubernetes pod内容器状态OOMKilled和退出码137全流程解析

大叶子不小的博客

02-01

6462

本文研究的都是确定性的问题，好像没有什么意义，话说回来，如果没有学习这些确定性问题的积累，又如何去应对不确定的问题呢？作者：免帅叫哥链接：https://www.jianshu.com/p/0a9718199428来源：简书著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

k8s部署失败常见原因

xiaoyi52的专栏

10-22

5654

1. 错误的容器镜像/非法的仓库权限其中两个最普遍的问题是：指定了错误的容器镜像。使用私有镜像却不提供仓库认证信息。这在首次使用 Kubernetes 或者绑定 CI/CD 环境时尤其棘手。让我们看个例子。首先我们创建一个名为 fail 的 deployment，它指向一个不存在的 Docker 镜像： $ kubectl run fail --image=rosskukulinski/dne:v1.0.0 然后我们查看 Pods，可以看到有一个状态为ErrImagePull或者ImageP

k8s最佳实践：部分业务POD内存持续泄露问题

Y先森0.0

05-16

3317

K8S部分业务POD内存持续泄露问题 1.前言线上K8S集群有极少量的PHP业务，它们的POD内存持续走高直到OOM，相信与特殊代码场景有关，需要展开分析。我从POD的内存监控原理入手，分析到底内存用到了哪些地方。 2.分析过程第一步：分析pod的内存限制原理容器化依赖Cgroup限制内存资源，Docker采集容器的内存使用量也是基于Cgroup技术实际上，Cgroup标准做法是...

k8s系列05-使用containerd和cilium部署kubeproxy-free的k8s集群

tinychen

05-24

1480

本文主要在centos7系统上基于containerd和stable版本（1.11.4）的cilium组件部署v1.24.0版本的k8s原生集群，由于集群主要用于自己平时学习和测试使用，加上资源有限，暂不涉及高可用部署。此外，由于cilium已经实现了对kube-proxy的一整套替代方案，这里部署k8s集群的时候会使用cilium的kubeproxy-free方案。此前写的一些关于k8s基础知识和集群搭建的一些方案，有需要的同学可以看一下。 1、准备工作 1.1 集群信息机器均为8C8G的虚拟机，硬

K8S容器 exitCode:137 OOM 导致节点重启 Kibana排查过程

天天开心鸭！

11-30

2493

Kibana日志信息： 2021-11-15 14:38:43.650 DEBUG 7 — [ main] o.s.c.e.PropertySourcesPropertyResolver : Found key ‘spring.cloud.stream.bindings.*****************’ in PropertySource ‘bootstrapProperties’ with value of type String 2021-11-15 15:23:36.304

k8s--docker状态码（很重要）

weixin_45697293的博客

08-15

1559

最常见的退出码，来回答两个重要问题：这些退出码是什么意思？导致该退出码的动作是什么？exit code：代表一个进程的返回码，通过系统调用 exit_group 来触发。在 POSIX 中，0 代表正常的返回码，而 1-255 代表异常返回码，不过一般错误码都是 1。这里有一张附表 Appendix E. Exit Codes With Special Meanings。...

记录一次 K8s pod 被杀的排查过程

lxw1844912514的博客

01-20

690

问题描述今天下午运维反馈说我们这一个pod一天重启了8次，需要排查下原因。一看Kiban日志，jvm没有抛出过任何错误，服务就直接重启了。显然是进程被直接杀了，初步判断是pod达到内存上限被K8s oomkill了。因为我们xmx和xsx设置的都是3G，而pod的内存上限设置的是6G，所以出现这种情况还挺诡异的。排查过程初步定位先找运维拉了一下pod的描述，关键信息在这里Containers: ...

记一次poi导入excel引起cpu跑满的问题

大道坦荡的博客

04-07

9117

记一次poi导入引起生产cpu跑满的问题生产应用机器配置:8C 16G 周日突然收到告警，cpu持续15分钟空闲时间小于10%,赶紧联系运维要日志,通过分析dump_high_cpu PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 28830 jbossuse 20 0 12....

CPU飙升，pod重启啦，快回来处理吧。

l12127556的博客

05-11

1316

一次cpu飙升的排查和生产环境的分析

容器内Java进程问题造成Pod重启的原因分析

学无止境

10-19

3941

重启原因容器健康监控探针每3S发送一次readiness、一次liveiness，3s超时，超时未响应再次重发，超过3次未响应，视为POD不健康，自动重启POD。Java应用单次FGC时间过长，当FGC时间出现超过6S时，会偶发极端情况3次拨测正好全部失败，导致POD重启;当GC时间超过9S时，三次拨测大概率全部失败，导致 POD重启。问题分析 JVM启动会自动获取环境信息，根据CPU、内存、...

k8s pod 一直重启 code 137 排查记录

真正的大师永远怀着一颗学徒的心

02-10

1万+

现象 k8s pod一直在重启，调度不起来排查 1. 首先看状态这个比较简单，我直接在页面上的(rancher查看api、查看/编辑yaml等都能看) 如图，找到containerStatuses，里面有个exitCode：137 网上搜了下错误码的意思：退出代码 0：一般为容器正常退出退出代码 1：由于容器中 pid 为 1 的进程错误而失败退出代码 137：由于容器收到 SIGKILL 信号而失败（手动执行或“oom-killer” [OUT-OF-MEMORY]） = 退出代码 139：

k8s常见报错解决

贾文超的博客

01-20

1万+

【报错】 The Service "kubernetes-dashboard" is invalid: spec.ports[0].nodePort: Forbidden: may not be used when `type` is 'ClusterIP' 【原因】如果在service中没有指定type类型，默认采用ClusterIP 【解决】 # prometheus-service.yaml --- spec: type: NodePort #加入 ports: - name:

K8S的10个常见失败问题的原因

B.I.T

04-30

1万+

1. Wrong Container Image / Invalid Registry Permissions 当pod状态为ErrImagePull或ImagePullBackOff时，通常是由于以下3个原因（在排查网络故障的前提下）：镜像tag写错镜像不存在，或拉取的镜像仓库地址写错没有拉取镜像的权限（漏配了imagePullSecrets） 2. Application Crash...

【k8s】——k8s的GC机制

汤庆

11-23

2296

一、前言一说到GC，很多人(包括我在内)第一反应是内存的垃圾回收，尤其是javaer们，面试最爱考的八股文就是java的垃圾回收。不过今天要说的这个k8s的GC和java的不是一回事。你可以理解为广义的垃圾回收，因为在k8s的世界里，万物皆是资源。而GC就是回收资源。Kubelet的GC功能将清理未使用的image和container。Kubelet每分钟对container执行一次GC，每5分钟对image执行一次GC。二、k8s GC机制 K8s 实现了一种「Casca...

k8s pod调用超时