我家自动化

这个屌丝很懒，什么也没留下！

热门标签

某项目性能测试问题排查

作者：我家自动化 | 2024-03-19 03:15:24

踩

性能测试问题排查

背景：

某现场有3套提提及集群，每套上有2个实例，test1/test2在一套（2+3），test3/test4在一套（2+6），test5/test6在一套（2+5），其中test1/test2底层是SSD+flash，其他两套则是hdd+flash

主要记录性能测试过程中发现某业务出现断流的情况，断流描述如下：

--压测1小时的结果说明------

1、05:42:37时间点，导致8086端口的所有消息全部断流一次。

2、06:02:28时间点，导致8086端口部分接口断流，部分接口波动很大，TPS到达个位数。

3、06:08:18时间点，导致8086端口部分接口断流，部分接口波动很大，TPS到达个位数。

主要优化过程如下：

1、增大redo大小到4g，增加redo组到16组 --无效

2、开监控，捞慢sql

3、长ping监控网络 --网络并无延迟

4、增大shared pool，减少imu读 --无效

5、test4切双机 --无效

6、关imu（in_memory_undo)测试 --无效，且断流更频繁，因为关imu会导致io访问更多，初步怀疑io问题

7、将redo由sys建到data --无效

8、重启所有存储节点测试 --无效

9、比较test3/test4集群和test1/test2集群的bios、flash卡固件、raid卡固件、hdd/ssd固件、ib驱动版本，均相同

10、开单给oracle

11、迁移问题用户到test1集群 --断流问题解决

12、test3/test4集群修复失败的安全加固项 --问题仍存在

13、test3/test4 redo建到flash卡组成的diskgroup --问题仍存在

14、test3/test4 关闭归档 --断流问题解决

15、test4开启归档，test3关闭归档 --断流问题不再复现，自此能确认是test3归档写入太大导致hdd盘达到瓶颈，导致test4受影响，出现断流问题

16、之后test3要建dataguard，需开归档，肯定会对test4产生影响，项目组最终决定把问题业务迁移到test1实例

整个问题发现到优化从3.28--4.5，持续一周左右，从网络->内存->安全加固，再怀疑到IO，最终定位是test3 redo量太大、归档写入太频繁导致底层HDD盘的IO达到瓶颈；test3 redo产生量大是因为某张大表每天insert 几亿数据，每秒的redo量达到27,626,403.0 ，26M/s，由于底层是hdd，IOPS(2000+)和吞吐都达到HDD盘的瓶颈（6块HDD做RAID5)

而差不多IOPS和吞吐的情况下，test1/test2集群的SSD盘%util只有不到10%

这是经过无数次测试才定位到的根因，整个过程其实很曲折

1、redo相关的整改

test4的awr日志log file sync等待为top 1，其次就是log file switch (private strand flush incomplete) ,且项目组指出某些日志组switch的时间与vc/etc断流的时间几乎一致。

初始没仔细研究，怀疑是redo组数8组太少，redo 2G太小，将redo增大为4G，12组

2、开启sql monitor

同时开启慢sql的抓取，看看到底是网络问题、业务主机hang，还是数据库问题

alter system set "_sqlmon_threshold"=1;

alter system set "_sqlmon_recycle_time"=30;

sqlmonitor介绍文章见 oracle sql monitor_Joyce.Du的博客-CSDN博客_oracle sqlmonitor

部署长ping脚本，检查是否是业务主机和数据库主机之间的网络问题，长ping发现断流时间点并无网络延迟

3、内存相关的测试

（1）增大shared pool

增大redo并没有任何效果，深入了解log file switch (private strand flush incomplete) 等待事件，发现此等待事件跟内存IMU有关联，而IMU是从shared pool中分配的一个模块，而test4的shared pool初始只有8G，算是较小，建议现场改为15G。

IMU是10g开始引入的特性，即IN Memory Undo，默认开启，由隐含参数_in_memory_undo确定是否开启，RAC的_in_memory_undo参数虽然为true，但rac默认是关闭IMU的。

但是增大shared pool并重启实例之后，KTI-UNDO大小并无改变，增大前后都是103M，增大shared pool也没有解决问题

（2）关闭IMU

想着既然可能是IMU导致log file switch (private strand flush incomplete)，尝试关闭IMU

alter system set "_in_memory_undo"=false;虽然不需要重启生效，但是重启后undo内存段才会释放

重启后：

关闭IMU断流问题更加频繁，从而初步怀疑是IO问题

改参数前断流：

05:03:32 ,0,0,0,0,0,0,0,0,0,0,0,0,-1

05:10:13

改参数后断流：

05:56:08,24,0,0,0,0,0,0,0,0,0,0,0,-1

05:56:09,0,0,0,0,0,0,0,0,0,0,0,0,-1

05:55:30,34,0,0,0,0,0,0,0,0,0,0,0,-1

05:57:32,0,0,0,0,0,0,0,0,0,0,0,0,-1

05:57:33,0,0,0,0,0,0,0,0,0,0,0,0,-1

05:57:34,0,0,0,0,0,0,0,0,0,0,0,0,-1

4、test3和test4互切双机

为了排除数据库主机问题，将test3和test4互切双机，但是断流问题仍旧存在，排除了计算节点的硬件问题

此时开单给oracle，看看有无其他思路

6、IO问题排查阶段1

iostat监控test3/test4集群在性能测试时的IO，因为redo放在sys里，监控sys盘发现iops很小，且吞吐很低的情况下，sys盘iobusy将近100%

iostat -xm 2 | awk '{print strftime("[%Y-%m-%d %H:%M:%S]"),$0; fflush(); }'

且发现redo切换归档5s才完成

（1）将test4的redo由sys磁盘组（非加速盘）建到data磁盘组（加速盘）

由于redo是顺序写，而加速盘的随机读写性能较好，所以建到data磁盘组断流问题也仍无改善

且data盘也有iobusy 100%的情况

同时发现同一个cDAS集群的TEST3也有iobusy 100%的情况，且TEST3的IOPS很小，吞吐将近为0

test5/test6集群也有相似的问题

（2）重启存储节点主机

由于存储节点安全加固之后未重启主机，停掉test3/test4的双机，重启存储节点，问题仍存在

7、此时无其他思路，只能将问题业务数据迁移到test1/test2集群

数据泵迁移断流业务对应的用户迁移到test1/test2集群，断流问题不再出现，怀疑是test3/test4某个时间点io hang住

8、集群硬件软件比较

比较test3/test4集群和test1/test2集群的bios、flash卡固件、raid卡固件、hdd/ssd固件、raid卡缓存读写比（90%读10%写）、ib驱动版本，除了盘类型不同（test1/test2是SSD，test3/test4是HDD），其他均相同

排查test3/test4集群，无硬件告警

9、test3/test4集群修复失败的安全加固项

经现场回忆，test3/test4集群，test5/test6集群和test1/test2集群除了盘类型不同，其他唯一的不同点就是安全加固时test3/test4和test5/test6存储节点直接升级导致数据库挂了，后来停target升级的；而test1/test2是有了经验，停target升级

检查安全加固脚本，发现一些安装的残留包没有清理干净，一一修复安全加固失败的项后，对test4进行表空间、插入测试，iobusy的情况不再存在，初步认为根因是安全加固失败导致

安全加固据说在所内的超融合集群已测试可以直接升级patch，但是现场是标准版，升级计算节点正常，升级存储节点失败，需要停掉target升级

set time on

set timing on

set serveroutput on;

drop table testpress.tba;

create table testpress.tba as select * from dba_objects;

declare

v_count integer;

begin

v_count := 1;

for v_count in 1..2000 loop

insert into testpress.tba select * from dba_objects;

dbms_output.put_line(' Insert for the '||v_count||' time.');

commit;

delete from testpress.tba;

end loop;

end;

业务再次测试还是反应有断流问题，现场监控发现test3的存储仍然有iobusy 100%的情况，经确认，TEST4跑性能测试时，TEST3的大表也在持续写redo

10、对hdd盘做fio测试

存储1：

lvcreate -L 100G -n lvtest11 vgdata11

lvcreate -L 100G -n lvtest12 vgdata12

lvcreate -L 100G -n lvtest13 vgdata13

fio --name=test --group_reporting --rw=randwrite --bs=8k --runtime=180 --ioengine=libaio --iodepth=10 --numjobs=10 --direct=1 -size=200g -time_based --filename=/dev/vgdata11/lvtest11 >>/soft/stg1_fio1

存储2：

lvcreate -L 100G -n lvtest21 vgdata21

lvcreate -L 100G -n lvtest22 vgdata22

lvcreate -L 100G -n lvtest23 vgdata23

存储3：

lvcreate -L 100G -n lvtest31 vgdata31

lvcreate -L 100G -n lvtest32 vgdata32

lvcreate -L 100G -n lvtest33 vgdata33

存储4：

lvcreate -L 100G -n lvtest41 vgdata41

lvcreate -L 100G -n lvtest42 vgdata42

lvcreate -L 100G -n lvtest43 vgdata43

存储5：

lvcreate -L 100G -n lvtest51 vgdata51

lvcreate -L 100G -n lvtest52 vgdata52

lvcreate -L 100G -n lvtest53 vgdata53

存储6：

lvcreate -L 100G -n lvtest61 vgdata61

lvcreate -L 100G -n lvtest62 vgdata62

lvcreate -L 100G -n lvtest63 vgdata63

随机写IOPS差不多2000，顺序写吞吐5GB/s，表现正常

11、创建flash卡组成的磁盘组

因为我们之前迁移到test1/test2集群可以解决断流问题，因为集群问题除了HDD盘不同，其他跟test1/test2集群都一致。怀疑会不会是test3影响了test4，就开始分析test3的awr，发现test3的吞吐在性能测试时达到400MB/s

因为是HDD的磁盘达到100%的iobusy，且现场的存储节点flash卡剩余很多，产品线提出可以将redo建在flash卡组成的磁盘组中，具体创建方法省略

创建之后将redo重建到新磁盘组，新建的redo组所在盘是没有iobusy 100%，但测试之后断流问题仍存在。此时真的是没啥思路了，只能让项目组评估将问题业务迁移到test1是否能承受

12、柳暗花明

oaadmin@omldbrbp1012[/soft]$ ll /dev/mapper/|grep dm-118

lrwxrwxrwx 1 root root 9 Apr 5 04:27 asm-arch522 -> ../dm-118

root@omldbrbp1012[/root]# ll /dev/mapper/ |grep dm-65

lrwxrwxrwx 1 root root 8 Apr 5 04:28 asm-sys212 -> ../dm-65

现场监控到将redo迁移到flash卡磁盘组，iobusy的盘是arch盘和sys盘，这两种盘是没进行加速的，怀疑是不是test3因为大表redo写入量大，归档也很频繁，导致HDD无法承受达到瓶颈，建议现场关闭test3的归档再测试

test3归档关闭后，断流问题不再复现，自此能确认是test3归档写入太大导致hdd盘达到瓶颈，导致test4受影响，出现断流问题

13、最终解决方法

因为之后test3要建dataguard，需开归档，肯定会对test4产生影响，项目组经过评估最终决定把问题业务迁移到test1实例

总结：

从发现问题到解决，中间走的弯路很多，对内存、网络、主机、存储都进行了排除测试，初始不能定位是IO问题，主要也是因为测试时没有可供参考的主机监控，后来加上iostat监控，才确定了存储IO达到瓶颈，可见监控对故障解决的作用。

TEST3由于从其他系统割接，存在cdr_***这一写入很大的表（每天insert几亿条记录，之前test3测试时已经凸显了它导致的各种问题，如index contention等），test4测试初始没考虑到test3和test4共享存储，test3会对test4造成那么大影响，所以只针对test4进行了排查，也是定位缓慢的原因。

由于大表的特殊性，经常将IO到100%，还是建议之后有此业务的test3集群用SSD存储而不是HDD存储

附：

test3/test4规划数据

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/我家自动化/article/detail/266771