一、现象:

          16点30分左右某服务飘红,重启之后,内存很快又爆掉,扩充实例到8台之后仍然不行,最后临时调大最大堆和最小堆到3g,暂时抗住。

二、原因分析:

          历史遗留问题,1年前某开发写代码时将,所有数据拼成一条sql去存储,随着数据量变大14w数据用一条sql怼到数据库导致服务宕机。         

三、Kibana日志:

服务宕机及优化

 

四、线上服务器配置:-xms2g -xmx2g 

               年轻代1G     老年代1G

服务宕机及优化

 

五、fullgc分析:

服务宕机及优化

 

 

服务宕机及优化

 

服务宕机及优化

六、问题代码:

服务宕机及优化

服务宕机及优化

        

服务宕机及优化

七、解决方案:

           1、业务上:

                      1、任务规则 乘 任务商品 总条数需要小于10w条,超过之后分批导入

                      2、防止同一文件重复提交

                      3、防止同一文件导入成功之后,多次重复导入

           2、技术上:

                      1、超过10w条,提示用户,分批导入

                      2、程序里list设置初始值,避免数组不断扩容

                        

服务宕机及优化

                      3、大数组拆分成多个小数组(500个一组),分批执行

 七、后续如何规避:

             排查项目里涉及到sql批量操作的地方,进行调整,避免大sql   

 

相关文章:

  • 2021-05-26
  • 2021-06-13
  • 2022-12-23
  • 2021-06-23
  • 2022-12-23
  • 2021-07-10
  • 2021-10-22
猜你喜欢
  • 2022-12-23
  • 2021-12-05
  • 2021-05-11
  • 2021-09-29
  • 2021-09-22
  • 2022-12-23
相关资源
相似解决方案