背景:
性能测试现在压力和瓶颈都体现在OM系统上,张同学尝试了很多种方案,解决结果不是很理想。
表象就是:Oracle 数据库Session飙升厉害,当Session达到最大配置后系统会由于很多应用请求得不到可用Session而超时。
Oracle数据库大部分Session被OM锁占用。同时在此期间,数据库表行锁也飙升,最近一次甚至飙升到了40K。
处理过程方法:
结合AWR和ADDM报告分析定位排查,及模型结构和并发量综合分析,本次的问题处理思路如下:
1、解决处理数据库ITL等待事件处理,此类事件产生的原因由于表的ITL的设置不能够满足并发事务的需求而导致的等待。
1.1)、对OM系统几张带有BLOB类型大表结构做了优化参数调整initrans=1改成10,同时对缓存表改成不生成日志模式。
--并发事物初始化参数调整
alter table SG_PRODUCTINST_PROATTR pctfree 10 initrans 10;
alter table SG_SERVICEORDERTICKET pctfree 10 initrans 10;
alter table SG_CUSTOMER pctfree 10 initrans 10;
alter table SG_CUSTOMERINFO pctfree 10 initrans 10;
alter table SG_PRODUCTINFO pctfree 10 initrans 10;
--缓存表调整
alter table SG_CRMDISPACHXML initrans 10 nologging;
alter table sg_imsystemxml initrans 10 nologging;
alter table sg_amsystemxml initrans 10 nologging;
alter table sg_wfmsystemxml initrans 10 nologging;
1.2)、对其中几张频繁读取次数高的索引,进行并发事物初始化参数调整到10
alter index IDX_ORDERTICKET_PARENTID rebuild PCTFREE 10 INITRANS 10;
alter index SYS_C0011847 rebuild PCTFREE 10 INITRANS 10;
alter index SYS_C0011853 rebuild PCTFREE 10 INITRANS 10;
alter index SYS_C0011958 rebuild PCTFREE 10 INITRANS 10;
2、解决处理HW-connection等待事件,此类事件产生主要是由于SG_WORKTICKETATTRVALUE瞬间并发插入事物大导致的。
将该表有针对性改造成hash分区,避免热点资源争用等待。
3、把数据库配置参数还原成19号值:
open_cursor=1000 和 filesystemio_options=NONE
4、经OSS预集成同事压测后结果如下:
19号测试情况: 总共发单8小时3分钟,发单总量114322,平均每秒发单3.96。 全部完单用时8小时49分,平均每秒完单3.6
23号测试情况: 总共发单8小时9分钟,发单总量129400,平均每秒发单4.3。 全部完单用时9小时8分,平均每秒完单3.8