一次数据仓库报表测试

Posted 2022-10-08 leebaul

1.背景

最近宝路接到了一个数据仓库报表POC的压测任务（就一个厂商为啥还叫POC….有点滑稽），本次记录下测试过程中遇到的问题及分析问题的思路。

2.测试环境架构图

发压策略：LR模拟业务人员->>某BI报表系统->>PostgreSQL集群3.遇到的问题

3.问题及分析

往PostgreSQL集群节点存放文件

PostgreSQL集群四台server是由一个管理节点进行统一管理的（宝路所使用的压力机无法直接链接），往目标服务器存放nmon监控文件就犯难了，即使用xshell从管理节点跳转到PostgreSQL节点（没有安装ftp），在使用xftp打开的仍然是管理节点传输文件窗口。

解决方法：使用scp命令

scp nmon admin@192.168.1.111:nmon  (在管理节点上执行，将nmon文件copy到指定服务器用户名目录下)

scp admin@192.168.10.111:baobiao1_10vu.nmon /home/admin/baobiao1_10vu_111.nmon  (把nmon结果文件从远程主机copy到当前用户目录下并重命名）

压测过程中遇到GC导致的问题

单交易负载测试过程中遇到了GC回收到导致的STW现象，来看一张xxBI 服务器资源消耗图：

在场景执行约9分半时发生了FUll GC，GC后CPU骤降，磁盘逻辑读翻了几倍。当前场景停止后，继续重跑此场景，xxBI 服务器资源消耗图：

。。。。再来看下LR的TPS趋势图：

action中的报表查询事务一笔都没有执行。。。。

不同的报表宝路都做了多次尝试都存在这个问题，那么是什么导致的呢？

1. 第一感觉还是GC，比如垃圾回收器用的不合理，像这种大内存，建议采用G1垃圾回收器（具体为啥G1垃圾回收器合适以后专门给大家写文章来讲GC那些事），一般常用的是parNew+CMS，试想发生FULL GC时，新年代+老年代的垃圾对象总大小是非常大的，这就造成很长时间的STW现象。
2. 如果xxBI系统就是采用的G1，发生FULL GC 后，讲道理场景重新执行，TPS也不会没有值。最大的可能是GC后，导致缓存失效了，此时我们的压测脚本采用的是匿名登陆（就是把压力机的IP配置到xxBI的白名单，访问报表就不需要登录了），怀疑此功能暂时失效。宝路尝试使用户正常从浏览器登陆xxBI系统进行查询报表，能正常查询，退出系统后查看任务管理器，CPU消耗约30%，嗯？此时并没有进行压测，这是为啥？猜测可能是这个操作触发了缓存。等CPU降下来后，再进线复测TPS曲线正常，再长时间压测就又出现FULL GC，然后。。。。。。

最后还是需要xxBI厂商的人来排查这个问题，其实最开始时就有这个现象，可碰巧那天PostgreSQL集群的人调整了内存相关参数，PostgreSQL集群的负责人把参数还原后，复测仍然有这个问题。