知识收集9【原创】

账套间大数据量同步的解决方案

    在忙于其他项目的开发过程中,突然有一家客户反馈一个大数据量问题,当物品基础数据等大数据同步到另一个账套时,系统就卡死,崩溃啦。

    我拿到用户的数据环境,用Visual GC监测工具,监测了一看皱眉


    整个的伊甸园内存区和旧时代内存区都爆满,jvm直接卡死,tomcat直接崩溃

在同步的时候,瞬间内存快速爆满,当时把我吓了一跳。

    开始的时候,想当然的认为加大内存就可以解决此问题,于是jvm的最大内存由原来的1024M,扩到

1500M,内存还是直接爆满。

    最好用Visual VM监测到,在同步的时候,产生了大量的实例对象,GC来不及回收,直接耗尽整个内存。

于是确定,可能是程序出了问题。

    于是,开始从程序一步一步的查找,开始的第一个方法,就是查询物品的数据量比较大4.7W多条,直接耗尽了可怜的本身就不大的内存哭。通过在群里,开发人员的讨论和建议,对于大数据量的查询,我做了分页形式的批量查询,然后批量处理数据,批量同步数据。

     但是,再同步的过程中,会产生逻辑问题,为了不改变现有的业务逻辑和数据问题,我把处理后的数据,一次同步过去,监控了下同步的过程中,系统还是可以承受的。

      可是,同步的过程中,时间问题产生了,同步一次,大约要至少3个小时,这是多么可怕的事情,我又遇到了同步的时间问题,我在思考究竟哪里消耗这么长的时间,于是又重新回归程序的定位,查找,看了一遍代码后,看到代码中很多不足之处,进行了一一优化,最终发现了有个xml文件读取,解析放到了循环里面,导致耗费大部分时间。设置了一个全局变量,值解析一次xml文件,然后循环过程中,都从这个变量里去取相应的配置信息。

     通过测试以后,时间终于降下来了,现在时间大约10分钟左右,这令我相当的振奋不已。

     不过在最后同步完数据的后处理时代,内存很快增高不少,于是定位到更新处理代码段的查询,也做了分页查询处理。眨眼

     另外,进行同步的过程中,发现JVM内存还是不是很稳定,总是升高,不往下降,为了保持内存跟趋于稳定,我每2W条的数据处理,就做一下 system.gc()垃圾回收,虽然会占用一点时间,但是对整体时间效率上还是可以接受的,这样做保证了系统趋于稳定。

     在往数据库同步的过程中,也做了基本的垃圾回收处理。

     优化后的处理结果如下图:大笑

     由于同步的业务逻辑校验,处理等都要耗费时间,在时间效率上还是稍微差点,但是整体上应该还是满足客户使用的。

     为了不使当前的页面卡死,把原来的同步提交,改成了异步提交处理。

     为了使同步的日志,加载到页面不至于卡死,改成了页面下载的模式,下载下来直接在txt文件里查看。

     以上,就是我做得一些基本优化。吐舌头

©️2020 CSDN 皮肤主题: 大白 设计师: CSDN官方博客 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值