数据量比较大的情况下直接导出可能会出现内存溢出

简介: 数据量比较大的情况下直接导出可能会出现内存溢出

故障原因
下午14:30左右服务器load明显飙升出现登录缓慢的情况



处理过程
根据告警信息提示,是应用服务器的load指标过高引起,查询ECS服务器的指标发现cpu在14:30左右出现明显飙升


load指标也有明显飙升



排查思路:
联系志成导出出现异常时间点附近的服务器日志,打开导出的jstack文件,发现cpu时间较高的线程


打开导出的dump文件,发现存在线程占用内存过高的情况



继续查看线程的堆栈信息,和jstack中找到的一致,发现是导出文件引起的异常现象



静态文件导出由于模版文件不会很大,所以理论上不大可能会出现这种情况,很大可能是导出动态生成的文件引起,由于数据量过大,导致导出过程内存占用过高
目前导出采用的是POI框架,导出使用的WORKBOOK为XSSFWORKBOOK,计划改成SXSSFWORKBOOK,这种WORKBOOK有提供一个包含rowAccessWindowSize参数的构造函数,这个参数表示内存可见条数,超过部分会存到磁盘上,需要在uat或其他环境做一下验证

暴露的问题
目前有部分文件导出采用的是同步的方式导出,在数据量比较大的情况下直接导出可能会出现内存溢出的情况

改进措施
计划采用SXSSFWORKBOOK设置内存可见条数的方式作为处理方案,在uat环境进行验证

若有收获,就点个赞吧


相关文章
|
缓存 easyexcel Java
Java EasyExcel 导出报内存溢出如何解决
大家好,我是V哥。使用EasyExcel进行大数据量导出时容易导致内存溢出,特别是在导出百万级别的数据时。以下是V哥整理的解决该问题的一些常见方法,包括分批写入、设置合适的JVM内存、减少数据对象的复杂性、关闭自动列宽设置、使用Stream导出以及选择合适的数据导出工具。此外,还介绍了使用Apache POI的SXSSFWorkbook实现百万级别数据量的导出案例,帮助大家更好地应对大数据导出的挑战。欢迎一起讨论!
1892 1
|
8月前
|
前端开发 开发者 异构计算
鸿蒙5开发宝藏案例分享---应用性能优化指南
本文介绍了鸿蒙应用性能优化的8大策略,涵盖状态刷新、渲染范围、组件绘制等方面。核心思想包括精准刷新(避免全局重绘)、控制渲染(减少不必要的组件更新)、优化绘制(降低布局计算开销)、使用并发(主线程轻量化)、减少节点(扁平化布局)、延时操作(提升启动速度)、优化动画(确保60fps流畅度)以及感知优化(用户优先)。通过具体代码示例,如懒加载、分帧渲染、异步处理等,帮助开发者实现高效优化。结尾强调性能优化是持续迭代的过程,需遵循“精准刷新、轻量化主线程、精简节点”三大原则,共同打造流畅体验。
|
算法 C++ 容器
C++初阶之一篇文章教会你queue和priority_queue(理解使用和模拟实现)(下)
优先队列是一种容器适配器,根据严格的弱排序标准,它的第一个元素总是它所包含的元素中最大的。 此上下文类似于堆,在堆中可以随时插入元素,并且只能检索最大堆元素(优先队列中位于顶部的元素)。 优先队列被实现为容器适配器,容器适配器即将特定容器类封装作为其底层容器
|
机器学习/深度学习 数据采集 算法
图像识别中的局限性
【10月更文挑战第1天】
1385 0
|
存储 算法 Shell
C++项目实战-多进程(一篇文章)(一)
C++项目实战-多进程(一篇文章)(一)
440 0
|
存储 并行计算 异构计算
显存优化综述
显存优化综述
978 1
显存优化综述
|
存储 关系型数据库 MySQL
【MySQL】事务日志 undo log 详解
Redo log是事务持久性的保证,Undo log是事务原子性的保证。在事务中更新数据的前置操作其实就是要写入Undo log。事务需要保证原子性,也就是事务中的操作要么全部完成,要么什么也不做。但有时候事务执行到一半会出现一些情况,比如: 情况一:事务执行过程中可能遇到各种错误,比如服务器本身的错误,操作系统错误,甚至是突然断电导致的错误。 情况二:程序员可以在事务执行过程中手动输入ROLLBACK语句结束当前事务的执行以上情况出现,我们需要把数据改回原先的样子,这个过程称之为回滚,这样就可以造成一个假象:这个事务看起来什么都没做,所以符合原子性要求每当我们要对一条记录做改动。

热门文章

最新文章