随笔- 154  文章- 0  评论- 41 

Saiku查询缓慢问题追踪(三十三)

 

emmmmm..... 好久没有再处理saiku相关问题了,这两天用户突然提了一个mantis bug,说有个报表查询慢,导出更慢,且导出的时候甚至可能会报错~(无法导出相关数据) 。惊了,我在想 saiku用了这么久都还挺正常的呀,且其它报表都没有问题,怎么这个报表就不行呢.....

 

定位问题:

页面上点击查询那个有问题的报表,执行查询的时候没有问题,就是时间长,但是执行导出的时候就导不出数据....

>> 1. 一开始我是查看后台日志的,发现等了很久 日志并没有任何错误信息,过了很长时间后 页面竟然报错了...

>> 2. 然后就在前端debug,给出的结果是 Time-out ! 接口超时啦~

 

1.top命令 看看那个进程CPU使用率最高

top  #得到PID 1865是CPU使用率过高的进程

 

2. 找到saiku的进程id

ps -ef|grep saiku  #得到进程id为 1865 ,咦,巧了  刚好就是你! Saiku

 

3.进去看看是那个线程有问题,一直让CPU飙升,持续在100以上!!!

top -Hp 1865  #这里的1865就是我们saiku的进程id,从下图可以看出我们的是id为 2377 的那个线程在搞事情!!

 

 4.jstack一下看看。(先把 2377 换成16进制  0x949 ,这便对应了jstack命令里面堆栈信息的nid,也就是线程id)

jstack 1865 >jstack_dump.log  #将堆栈信息打印到当前目录的jstack_dump.log文件中,然后拿到本地看看

 

5.在 jstack_dump.log文件中全局搜索 nid=0x949 的线程堆栈信息

 

6.从以上堆栈可以明确定位问题代码啦

这是在数据导出Excel的时候有问题啦(org.saiku.service.util.export.excel.ExcelWorksheetBuilder)

 

 

这里是调用 Sheet的 autoSizeColumn 方法,就是自适应列宽,卡在这里我就好奇了,为啥其它报表1w+的数据导出都没有问题,为什么这个报表3000+的数据就在这里卡住了呢

后来发现,是因为这个报表的格式有太多的自动合并了数据列了,导致在autoSizeColumn这一步的时候卡死了,其它报表是单独的行,规规矩矩的行数据信息,所以就没有这个问题。

 

 

解决方案:

将最细的那列数据挪到报表的开头(直接在saiku里面拖拽到维度的第一个就可以了啦),这样子结果报表就不会自动合并了

再去查询或者导出就很快了,比之前快了7~8倍(查询),导出就更快了哈哈哈哈

其实最初的时候我在想是不是查询太慢了,就先查了数据库,发现这张表上竟然没有加索引,正常来说我们的报表数据都会按照日期查询,所以都会在日期字段上加索引的,然后我就先加了个索引,发现问题还是存在,就出现了如上步骤啦~(索引还是加了,查询也快了不少)

 

 posted on 2020-04-13 19:42  阿叮339  阅读(118)  评论(0编辑  收藏