性能测试工具 记一次内部测试平台的性能故障分析排查过程

ELes for PPmoney · January 23, 2019 · Last by ELes replied at January 24, 2019 · 1026 hits

第一次报障

1、执行用例总是提示获取到dataprovider获取到的Object[][]为空

Object[][]为空.png

2、在本地调试并不能每次复现,重启一下服务器就能好。没有明显的报错日志。

第一次问题定位

1、运行调试,发现总是读取表格文件的这一步

读取表格文件.png

发现这里的错误只捕获了IOException。于是在抛出错误的时候,将IOException调整为Exception

修改为捕获Exception.png

一开始捕捉到的是一个NullPointException

于是第一次的解决方案是:加多一个NullPointException。

加多一个NullPointException.png

由于本地运行正常,所以就上线了并告诉大家修复了问题。

第二次报障

上线后,测试同学小美仍然反馈出执行不了的问题,然后重启之后,原本的文件就能够正常执行了,但是再上传一个新文件执行,同样会报这个错。

第二次问题定位

1、此时发现测试同学小美所使用的表格文件特别大。正常情况下只有200k左右的用例文件,执行有问题的文件居然高达4M。

文件很大.png

考虑可能是4M的文件解析带来的问题,

于是在抛出错误的时候,再次调整为Exception

修改为捕获Exception.png

【重现步骤】

1、先执行一次4M的文件的用例

2、执行完成后再上传一个4M的用例(上传用例过程在线上执行,直连线上的数据库,然后复制一份用例文件到本地执行)

3、使用新的文件执行用例

此时明确发现,是由于OOM内存溢出导致的问题

OOM.png

于是打开jprofiler进行分析

1、第一次运行4m文件

第一次运行4M.png

再上传一个新的4m文件,然后执行用例(上传用例过程在线上执行,直连线上的数据库,然后复制一份用例文件到本地执行)。

直接内存占用高达1.62G,GC100%运行,CPU未出现过载,所以性能瓶颈点主要在内存。判断可能存在内存泄漏。

第二次运行4M.png

GC活动.png

cpu占用.png

另外还发现:超时还可能导致无法连接上zk,导致后续的测试无法继续执行

[图片上传失败...(image-5f70f9-1548245913902)]

但从上面只能定位到可能是内存泄漏,但未能定位到是什么原因导致,于是我们转向Live Memory

打开jprofiler的Live Memory,执行如下步骤:

1、先执行两个普通大小用例文件的用例,观察内存中那类占用比较多--此时没发现什么异常(所以没有截图)

2、再执行一个4M大小的用例。

发现下图中AttrXobj、ElementXobj暴涨。几乎占据了图中80%以上的量。

(后续还执行了第二个4M文件,但由于直接跑崩了所以没有收集到第二次4M文件执行的内存数据)

Live Memory.png

然后搜索AttrXobj(搜索AttrXobj),得知该类与XSSFWorkbook有关。

搜索结果.png

并且

1、从第一条搜索结果可知(SXSSFWorkbook & XSSFWorkbook 效率比拼)XSSFWorkbook本身在大数据量下存在性能问题。

image.png

2、在第四条记录上看到了非常类似情况:记一次FullGC的排查

image.png

所以基本上定位到问题是处在我们ExcelUtils中用到的XSSFWorkbook对象身上。

最终解决思路

第一个:像记一次FullGC的排查这样限制用户上传文件大小

思考:虽然该方法成本最低。但由于用例文件可能会存放多个sheet,即使单个sheet数据量不超过100k,整个excel文件的总size无法预估,且无法解决根本问题,所以先不采取这个方法。

第二个:检查内存泄漏点,解决内存泄漏

从下图中可发现,黄框部分是执行完GC之后的内存占用情况,随着用例执行而增多。

内存占用趋势.png

读取表格方法的源码.png

结合两图可以定位到是XSSFWorkbook的问题。那我们关注到调用这个类的方法上。

从下图中可以看到,在方法中,有一个FileInputStream对象,但是读取了之后没有对应的关闭方法。

excelWBook、excelWsheet这两个对象是一个静态对象,在执行完操作之后,却没有进行对象的清空。可能会一直存活着。

从代码里也可以看到一个点:excelWBook这个变量是一个静态变量,第一次读取4M文件后,未被释放。然后到了第二次读取的时候,

excelWBook = new XSSFWorkbook(ExcelFile) 

先执行new XSSFWorkbook(ExcelFile) 再将new出来的对象赋值给excelWBook。所以 此时 excelWBook占用一波内存,new XSSFWorkbook(ExcelFile)又要占用一波内存,导致直接内存爆掉了。

修复前内存情况.png

【优化点】

1、将excelWSheet、excelWBook、cell从静态变量改为实例变量,释放内存。

2、加一个try-finally/try-with-resource关闭FileInputStream文件流。

3、使用SXSSFWorkbook替换XSSFWorkbook,降低内存开销。

参考文档

IntelliJ IDEA集成JProfiler,入门教程

SXSSFWorkbook & XSSFWorkbook 效率比拼

记一次FullGC的排查

修复结果

多次执行4M大小的文件响应正常且内存稳定。

修复后内存情况.png

修复后的关键源码

public static Object[][] getTableArray(String FilePath, String SheetName, int totalCols, Boolean isWithTitleRow) throws IOException {
String[][] tabArray = (String[][])null;
FileInputStream excelFile = null;

try {
excelFile = new FileInputStream(FilePath);
XSSFWorkbook excelWBook = new XSSFWorkbook(excelFile);
XSSFSheet excelWSheet = excelWBook.getSheet(SheetName);
int startRow = 0;
int startCol = 0;
int lastRowNum = excelWSheet.getLastRowNum();
int lastCol = totalCols - 1;
if (isWithTitleRow) {
startRow = 1;
}

int totalRow = getRealRowNum(excelWSheet, startRow, lastRowNum, startCol, lastCol);
if (isWithTitleRow) {
tabArray = new String[totalRow][totalCols];
} else {
tabArray = new String[totalRow + 1][totalCols];
}

for(int currentRow = startRow; currentRow <= totalRow; ++currentRow) {
for(int currentCol = startCol; currentCol <= lastCol; ++currentCol) {
tabArray[currentRow - startRow][currentCol] = getCellData(excelWSheet, currentRow, currentCol);
}
}
} finally {
if (excelFile != null) {
excelFile.close();
}

}

return tabArray;
}
共收到 2 条回复 时间 点赞

想不通为啥不用csv,excel在低并发系统里我们都会限制在2M以内,只能用文件流处理,不允许一次加载到内存,而且文件流处理也要非常谨慎。
虽然过程看起来比较长知识,总觉得没太care别人踩过的坑,有点找不自在的意味😂

ELes #2 · January 24, 2019 作者
槽神 回复

emm,因为做这个工具之前大家都是用excel跑的用例,而且习惯用excel的颜色标记去记录有问题的用例所以就没有改成csv格式了。正常情况下我们的用例文件只有200多k所以也没有做这块的限制。
在开发方面我的经验比较少,应该有很多应该优化的地方我没有考虑到 只关注到自己踩的坑了。如果你也有踩过不一样的坑,欢迎分享呀~也许我现在没踩到后面就踩到了XD

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up