记一次老商家端应用内存突然飚高原因分析 | 京东物流技术团队

京东云开发者
• 阅读 240

一、排查过程

问题发现是因为当时接到了内存UMP报警信息,如下:

记一次老商家端应用内存突然飚高原因分析 | 京东物流技术团队

通过查看PFinder发现内存一直在增长,没有停止迹象,触发fullGC也并没有下降趋势:

记一次老商家端应用内存突然飚高原因分析 | 京东物流技术团队

当机立断,先立即去NP上摘除了此台机器流量,然后继续观察,发现内存依然在不断增长。

记一次老商家端应用内存突然飚高原因分析 | 京东物流技术团队

随即查看故障分析,并没有得到有效信息:

记一次老商家端应用内存突然飚高原因分析 | 京东物流技术团队

因为流量已经摘除,那么继续观察到底哪里的问题,约半小时后然后接到了机器的宕机告警如下:

记一次老商家端应用内存突然飚高原因分析 | 京东物流技术团队

由于在应用启动参数里配置了dump路径,那么就马上去把dump文件下载下来分析。

记一次老商家端应用内存突然飚高原因分析 | 京东物流技术团队

随后找到对应IP机器的目录,下载了dump文件java_pid432.hprof核对时间没有问题,随即使用MAT工具开展分析,通过泄露分析结果直接就可以看出problem1与problem2都是一个同一个问题,2个线程分别占用1.8G、1.5G:

记一次老商家端应用内存突然飚高原因分析 | 京东物流技术团队

通过查看问题对应的代码类方法,发现该方法功能是"导出WMS保质期商品数据",该方法会调用库存分页接口查询保质期商品,大致如下:

1、查询无数据直接导出空表;

2、第一页查询总量小于1000的话直接把数据写入第一个sheet并导出表格;

3、第一页查询总量大于1000则循环分页查询,每1000条数据生成一个sheet表格进行导出。

可以看到,org.apache.poi.hssf.usermodel.HSSFWorkbook对象数量已经达到702个了。

记一次老商家端应用内存突然飚高原因分析 | 京东物流技术团队

翻看具体代码部分如下:

记一次老商家端应用内存突然飚高原因分析 | 京东物流技术团队

二、解决思路

经过对该功能代码分析,本着先解决问题的原则,先将循环调用功能进行限制,通过ducc配置导出页数大小限制,来避免一直循环调用。

记一次老商家端应用内存突然飚高原因分析 | 京东物流技术团队

至此,问题初步解决完毕,调整后没有出现问题。

但是,这个功能的优化并没有结束,随后将该问题及功能逻辑反馈给产品及库存相关方,一起讨论解决商家导出的问题,一方面我们要保障商家体验,另一方面又要确保系统稳定性。后续要从这2方面入手进行功能的优化,不断为提升商家体验而努力。

三、总结分析

回过头来咱们再分析以下这个功能,通过系统日志及监控,发现该功能商家日常使用较少,并且大部分商家的保质期商品较少,极少数会存在有非常多保质期商品数据的情况。但是一旦出现这样的问题就会很致命,所以在导出功能设计之初我们就应该考虑到将来任何可能出现的情况,并做好提前的预防。另外就是要做功能的限制,例如导出次数、导出数据量的限制功能来保障商家体验及系统的安全稳定。

另外再说一下,对导出功能的理解,对于商家而已,导出需求是正常的。但是过多大批量数据的一起导出无论对哪个系统来说都是非常危险的一个功能。以下列举了一些个人总结的导出功能设计时的一些常见规则,希望大家一起参与讨论分析,拙见如下:

  • 明确导出数据的价值分析
  • 明确导出数据的使用倾向
  • 明确导出数据的安全要求
  • 明确导出数据的权限控制
  • 明确需要导出的数据量级
  • 明确导出数据的方式方法
  • 明确到仓数据的频率频次
  • 明确导出数据的性能效率
  • 明确导出数据的限制方法
  • 明确导出功能的隔离及降级方案
  • 明确导出数据的格式样式
  • 明确导出数据的下载方案
  • 明确导出数据的错误监控

以上是个人想到的一些导出设计的简单规则,需要产研测一起沟通明确,还希望大家多提提意见,一起完善导出规则。

另外我们再从商家角度来考虑一下导出的目的,个人从询问业务及相关人员,发现商家导出数据有以下一些目的:

  • 存储归档方便查历史资料
  • 利用系统业务数据进行数据分析已指导商家业务工作或给领导汇报工作
  • 导出来使用表格工具等其他商家熟悉的工具进行查看,更便捷便利
  • 对导出的数据进行加工,并用于其他非京东系统的数据输入
  • 无意识的导出并无其他作用

以上是个人总结的一些商家导出的需求目的,其实针对商家导出来说可能还有很多其他目的,我们不能全部都能了解。但是可以积极与商家沟通理解商家的真实目的。

另外,我们需要去分析商家的诉求,挖掘商家需求背后的目的。假如有个服装行业的商家需要做服务订单业务数据、库存数据分析,是否我们可以利用数智侧的系统能力,为商家打造通用的数据分析能力呢,这样既可以避免导出数据手动分析的鸡肋,同时也提升了商家对京东物流的系统使用体验。

以上仅仅代表个人观点,一点愚见,还请大家批评指正!

欢迎大家一起探讨!

作者:京东物流 刘邓忠

来源:京东云开发者社区 自猿其说Tech 转载请注明来源

点赞
收藏
评论区
推荐文章
Linux内存泄露案例分析和内存管理分享
作者:李遵举一、问题近期我们运维同事接到线上LB(负载均衡)服务内存报警,运维同事反馈说LB集群有部分机器的内存使用率超过80%,有的甚至超过90%,而且内存使用率还再不停的增长。接到内存报警的消息,让整个团队都比较紧张
线上FullGC问题排查实践——手把手教你排查线上问题 | 京东云技术团队
作者:京东科技韩国凯一、问题发现与排查1.1找到问题原因问题起因是我们收到了jdos的容器CPU告警,CPU使用率已经达到104%观察该机器日志发现,此时有很多线程在执行跑批任务。正常来说,跑批任务是低CPU高内存型,所以此时考虑是FullGC引起的大量C
Wesley13 Wesley13
3年前
TCP滑动窗口消息堆积
线上问题:客户端不能推送数据到服务端。排查:pingip或者telnetport全是正常的,不奏效。通过wireshark抓取报文查看,发现一个奇怪现象是窗口不固定,但是整体趋势是逐渐减小,直到为0.服务端报文如下:至
Stella981 Stella981
3年前
SpringBoot整合Redis乱码原因及解决方案
问题描述:springboot使用springdataredis存储数据时乱码rediskey/value出现\\xAC\\xED\\x00\\x05t\\x00\\x05问题分析:查看RedisTemplate类!(https://oscimg.oschina.net/oscnet/0a85565fa
Easter79 Easter79
3年前
SpringBoot整合Redis乱码原因及解决方案
问题描述:springboot使用springdataredis存储数据时乱码rediskey/value出现\\xAC\\xED\\x00\\x05t\\x00\\x05问题分析:查看RedisTemplate类!(https://oscimg.oschina.net/oscnet/0a85565fa
Stella981 Stella981
3年前
Executors使用不当引起的内存泄漏
线上服务内存溢出这周刚上班突然有一个项目内存溢出了,排查了半天终于找到问题所在,在此记录下,防止后面再次出现类似的情况。先简单说下当出现内存溢出之后,我是如何排查的,首先通过jstack打印出堆栈信息,然后通过分析工具对这些文件进行分析,根据分析结果我们就可以知道大概是由于什么问题引起的。关于jstack如何使用,大家可以先看看这篇文章
Stella981 Stella981
3年前
Linux应急响应(二):捕捉短连接
0x00前言​短连接(shortconnnection)是相对于长连接而言的概念,指的是在数据传送过程中,只在需要发送数据时,才去建立一个连接,数据发送完成后,则断开此连接,即每次连接只完成一项业务的发送。在系统维护中,一般很难去察觉,需要借助网络安全设备或者抓包分析,才能够去发现。0x01应急场景​
Wesley13 Wesley13
3年前
MySQL部分从库上面因为大量的临时表tmp_table造成慢查询
背景描述Time:20190124T00:08:14.70572408:00User@Host:@Id:Schema:sentrymetaLast_errno:0Killed:0Query_time:0.315758Lock_
记一次Native memory leak排查过程 | 京东云技术团队
Nativememoryleak的排查思路与堆内内存排查类似,主要是以分时dump和对比为主。通过观察异常值或异常增长量的方式,确定问题原因。
京东云开发者 京东云开发者
1星期前
Linux内存泄露案例分析和内存管理分享
作者:京东科技李遵举一、问题近期我们运维同事接到线上LB(负载均衡)服务内存报警,运维同事反馈说LB集群有部分机器的内存使用率超过80%,有的甚至超过90%,而且内存使用率还再不停的增长。接到内存报警的消息,让整个团队都比较紧张,我们团队负责的LB服务是零