首页 > 其他分享 >案例分享-full gc导致k8s pod重启

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

时间：2023-05-04 09:55:05浏览次数：48  
标签：full 0000 04 secs gc 2023 22T14 2097151K 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/http: request canceled (Client.Timeout exceeded while awaiting headers)
Normal   Killing    2m56s                   kubelet            Container enterprise-service failed liveness probe, will be restarted

熟悉的健康检查失败（超时），是什么导致超时呢，继续找日志。

3.结合之前的排查经验，我认为gc的嫌疑最大，所以查看gc日志

贴一部分日志，可以看到Full GC很繁忙，而且每次结束后内存几乎没有释放，应用已经是处于停摆状态，接下来要做的就是找出Full GC的凶手。

2023-04-22T14:30:58.772+0000: 574.764: [Full GC (Allocation Failure) 2023-04-22T14:30:58.772+0000: 574.764: [Tenured: 2097151K->2097151K(2097152K), 3.6358812 secs] 2569023K->2568977K(2569024K), [Metaspace: 119379K->119379K(1163264K)], 3.6359987 secs] [Times: user=3.64 sys=0.00, real=3.63 secs] 
2023-04-22T14:31:02.410+0000: 578.402: [Full GC (Allocation Failure) 2023-04-22T14:31:02.410+0000: 578.402: [Tenured: 2097151K->2097151K(2097152K), 3.5875116 secs] 2569023K->2568980K(2569024K), [Metaspace: 119379K->119379K(1163264K)], 3.5876388 secs] [Times: user=3.59 sys=0.00, real=3.59 secs] 
2023-04-22T14:31:05.999+0000: 581.991: [Full GC (Allocation Failure) 2023-04-22T14:31:05.999+0000: 581.991: [Tenured: 2097152K->2097151K(2097152K), 3.5950824 secs] 2569024K->2568987K(2569024K), [Metaspace: 119379K->119379K(1163264K)], 3.5951774 secs] [Times: user=3.59 sys=0.00, real=3.60 secs] 
2023-04-22T14:31:09.596+0000: 585.587: [Full GC (Allocation Failure) 2023-04-22T14:31:09.596+0000: 585.587: [Tenured: 2097151K->2097151K(2097152K), 3.5822343 secs] 2569023K->2568849K(2569024K), [Metaspace: 119379K->119379K(1163264K)], 3.5823244 secs] [Times: user=3.58 sys=0.00, real=3.58 secs] 
2023-04-22T14:31:13.180+0000: 589.172: [Full GC (Allocation Failure) 2023-04-22T14:31:13.180+0000: 589.172: [Tenured: 2097151K->2097151K(2097152K), 3.6316461 secs] 2569020K->2568910K(2569024K), [Metaspace: 119380K->119380K(1163264K)], 3.6317393 secs] [Times: user=3.63 sys=0.00, real=3.64 secs] 
2023-04-22T14:31:16.813+0000: 592.805: [Full GC (Allocation Failure) 2023-04-22T14:31:16.813+0000: 592.805: [Tenured: 2097151K->2097151K(2097152K), 3.6070671 secs] 2569021K->2568907K(2569024K), [Metaspace: 119380K->119380K(1163264K)], 3.6071998 secs] [Times: user=3.60 sys=0.00, real=3.60 secs] 
2023-04-22T14:31:20.425+0000: 596.417: [Full GC (Allocation Failure) 2023-04-22T14:31:20.425+0000: 596.417: [Tenured: 2097151K->2097151K(2097152K), 4.7111087 secs] 2569020K->2568899K(2569024K), [Metaspace: 119381K->119381K(1163264K)], 4.7112440 secs] [Times: user=4.71 sys=0.00, real=4.71 secs] 
2023-04-22T14:31:25.142+0000: 601.133: [Full GC (Allocation Failure) 2023-04-22T14:31:25.142+0000: 601.133: [Tenured: 2097151K->2097151K(2097152K), 3.8752248 secs] 2569023K->2568899K(2569024K), [Metaspace: 119381K->119381K(1163264K)], 3.8753506 secs] [Times: user=3.88 sys=0.01, real=3.87 secs] 
2023-04-22T14:31:29.021+0000: 605.012: [Full GC (Allocation Failure) 2023-04-22T14:31:29.021+0000: 605.012: [Tenured: 2097151K->2097151K(2097152K), 3.5892311 secs] 2569023K->2568910K(2569024K), [Metaspace: 119381K->119381K(1163264K)], 3.5893335 secs] [Times: user=3.59 sys=0.00, real=3.59 secs] 
2023-04-22T14:31:32.612+0000: 608.604: [Full GC (Allocation Failure) 2023-04-22T14:31:32.612+0000: 608.604: [Tenured: 2097151K->2097151K(2097152K), 3.5236182 secs] 2569023K->2568915K(2569024K), [Metaspace: 119381K->119381K(1163264K)], 3.5237085 secs] [Times: user=3.52 sys=0.00, real=3.52 secs]

背景知识

我们的服务部署在k8s中，k8s可以对容器执行定期的诊断，要执行诊断，kubelet 调用由容器实现的 Handler （处理程序）。有三种类型的处理程序：

  • ExecAction：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。

  • TCPSocketAction：对容器的 IP 地址上的指定端口执行 TCP 检查。如果端口打开，则诊断被认为是成功的。

  • HTTPGetAction：对容器的 IP 地址上指定端口和路径执行 HTTP Get 请求。如果响应的状态码大于等于 200 且小于 400，则诊断被认为是成功的。

每次探测都将获得以下三种结果之一：

  • Success（成功）：容器通过了诊断。

  • Failure（失败）：容器未通过诊断。

  • Unknown（未知）：诊断失败，因此不会采取任何行动。

针对运行中的容器，kubelet 可以选择是否执行以下三种探针，以及如何针对探测结果作出反应：

  • livenessProbe：指示容器是否正在运行。如果存活态探测失败，则 kubelet 会杀死容器， 并且容器将根据其重启策略决定未来。如果容器不提供存活探针， 则默认状态为 Success。

  • readinessProbe：指示容器是否准备好为请求提供服务。如果就绪态探测失败， 端点控制器将从与 Pod 匹配的所有服务的端点列表中删除该 Pod 的 IP 地址。初始延迟之前的就绪态的状态值默认为 Failure。如果容器不提供就绪态探针，则默认状态为 Success。

  • startupProbe: 指示容器中的应用是否已经启动。如果提供了启动探针，则所有其他探针都会被 禁用，直到此探针成功为止。如果启动探测失败，kubelet 将杀死容器，而容器依其 重启策略进行重启。如果容器没有提供启动探测，则默认状态为 Success。

                                                                                              

以上探针介绍内容来源于https://kubernetes.io/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes

寻找原因

前面提到是由于Full GC STW导致jvm无法提供服务，那我们就看看是什么导致Full GC，具体的手段就是获取heap  dump文件，然后分析，什么时机去获取呢？

这里采用的办法是守株待兔，开两个窗口，一个盯着gc日志，当看到有大量Full GC产生时在另一个窗口生成heap dump文件。

接下来通过Eclipse MAT工具分析dump文件

 原因一目了然，是导出excel导致，涉及的数据接近10w条，且列比较多。

分析代码

大概看了一下导出的代码，问题集中在以下四点:

1.查询数据没有使用分页；

2.使用的Apache poi工具本身性能不好，内存占用过高；

3.导出没有限流，对于极度消耗资源的操作必须要控制并发，保护系统；

4.同步导出，用户等待时间过长时会选择重试，对系统来讲是雪上加霜。

改进措施

1.查询分页，保证往excel写数据时内存中只会有一页数据；

2.使用性能更好的工具，如easyexcel;

3.异步导出，控制同时导出的并发数；

经过这三步改造以后，导出导致的Full GC问题得以改善，上线一周再没有发现由于大数据量的导出导致的pod重启问题。

推荐阅读

1.容器服务pod异常排查

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

2.通过Exit Code定位 Pod 异常退出原因

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

3.pod异常问题排查

https://help.aliyun.com/document_detail/412618.html#6

4. easyexcel

http://easyexcel.opensource.alibaba.com/

　　

 

　　

　　

 

标签：full,0000,04,secs,gc,2023,22T14,2097151K,pod
From： https://www.cnblogs.com/chopper-poet/p/17369492.html

相关文章

  • 基于springcloud实现的医院信息系统
    访问【WRITE-BUG数字空间】_[内附完整源码和文档]医疗信息就诊系统，系统主要功能按照数据流量、流向及处理过程分为临床诊疗、药品管理、财务管理、患者管理。诊疗活动由各工作站配合完成，并将临床信息进行整理、处理、汇总、统计、分析等。本系统包括以下工作站：门诊医生工作站、药房......
  • SpringCloud gateway谓词
    1、AfterRoutePredicateFactoryAfter路由谓词工厂接受一个参数，一个日期时间（它是一个javaZonedDateTime）。此谓词匹配在指定日期时间之后发生的请求。例如：spring:cloud:gateway:enabled:trueroutes:-id:Goods-Server#路由id，唯一标识......
  • SpringCloud之gateway使用
    使用SpringCloudGateway是为了取代Zuul而开发出来的新一代网关，采用了响应式编程。 新建ModuleGatewayServer,添加依赖：<dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-gateway</artifactId></depe......
  • SpringCloud服务注册与发现(Eureka)
    0、前言   微服务是近两年比较火的概念，被称为程序员必备技能之一了，可见其运用之广。最近整理下资料进行系统的学习，与大家一一分享。    微服务是相对于传统单体式架构而言的。单体式架构是一份代码，部署都是基于单个单元进行的，它的优点是易于部署，但面临的就是可用性低......
  • SpringCloud服务注册中心双节点集群(Eureka集群)
    0、前言    最近在进行重构一个新项目，为了后续更好的落地，适应于日新月异的技术更新，进行了各方的技术选型及技术预研，最终选型基于微服务架构体系进行开发重构。项目构建前最重要的一步就是要想清楚，整体的部署架构、高可用性(HA)等等，做好前期的部署架构技术调研，确定最终方案......
  • SpringCloud之Seata（一）
    思维导图1.概述1.1概念Seata是一款开源的分布式事务解决方案，提供高性能和简单易用的分布式事务服务。2.事务概述2.1角色TC（(TransactionCoordinator)）：事务协调者：维护全局和分支事务的状态，驱动全局事务提交或回滚。TM(TransactionManager)：事务管理器：定义全局事务的范围：开......
  • 第14讲 AXI_FULL_4CH显示通路搭建
    FPGA与ARM大小端的问题，在做FPGA移位拼接时，将先到的数据放到了高位，放在DDR中的数据顺序应该是按照地址0123排列0123数据，即高位数据放在低地址，也就是所谓的大端模式，然后在SDK中，将DDR中的数据同步到ARM时，由于ARM采用的是小端模式，所以按照地址0123存放的数据是3210，也就......
  • 第12讲 AXI_FULL-HP显示通路搭建
    对于AXIInterconnect的输出引脚     ......
  • kirkland full synthetic motor oil 5w-30 全合成机油
    对比ax510w-30有质的提升。。ax5毕竟半合成。这是我头一次在摩托上面用这种全合成，效果还挺好的，低速加速非常丝滑(ax5那个半合成，低速涩涩的，提到30以上就很丝滑)实拍图片正面反面价格主打的一个便宜大碗。貌似现在也不便宜，6qt一箱180元样子，30元一瓶在国内的话costca可以......
  • 第11讲 AXI_FULL自定义总线详解
    DDR3 IP基础知识  (1条消息)快速上手XilinxDDR3IP核----汇总篇（MIG）_ddr3xilinx_孤独的单刀的博客-CSDN博客DDR3_MIG_TB   moduletop(  output    [31:0]   c);localparam[15:0]  a=65535;localparam[15:0]  b=25687;assignc=a*......

赞助商

阅读排行

网站主页关于我们联系我们网站地图

本网站内容转载自其他媒体，侵权联系[admin##ips99.com]。

Copyright © 2020-2023 IPS99 版权所有 IPS99