最近几天对客户的一个核心数据库进行了优化,将资源消耗较高的SQL优化完成之后,物理读和逻辑读总量得到了降低。客户反馈优化后性能有提升,但仍然在某些工作日的业务高峰时段存在性能问题。
我们通过将性能不佳的业务高峰时段(即问题时段)与性能正常的业务高峰时段(即基线时段)的性能数据进行了对比,发现了一些问题:
基线时段为2014-1-15日上午8:00-上午9:00,此时段TPS(每秒事务量)为:46T/s,该时段的总DB Time为:626.2 (mins)
问题时段为2014-1-20日上午8:00-上午9:00,此时段TPS为:47T/s(仅比基线时段多1T/s,可认为两者业务量相当),该时段的总DB Time为2361.4 (mins)
同样均为1小时的取样时间段,问题段的总DB Time是基线的近4倍,而通过对比两者的性能视图,发现问题时段的单次IO延迟非常高,如下:
Event Waits Time(s) Avg wait (ms) % DB time Wait Class
DB CPU 2,082 55.42
db file sequential read 62,140 774 12 20.61 User I/O
direct path read 177,440 575 3 15.31 User I/O
log file sync 17,486 145 8 3.86 Commit
gc cr block 2-way 98,519 30 0 0.80 Cluster
基线时段单次序列读延时为12ms,单次直接读延时为3ms,单次redolog写延时为8ms,
Event Waits Time(s) Avg wait (ms) % DB time Wait Class
direct path read 180,200 4,643 26 32.77 User I/O
db file sequential read 55,483 2,286 41 16.13 User I/O
DB CPU 1,917 13.53
gc buffer busy acquire 5,513 1,474 267 10.40 Cluster
log file sync 17,541 1,298 74 9.16 Commit
而问题时段单次序列读延时为41ms,单次直接读延时为26ms,单次redolog写延时为74ms
(Oracle文档中建议的单次IO正常延时应为0-20ms,否则需升级硬件),
即相比基线时段,在业务量不变的情况下,问题时段的IO效率下降非常明显,怀疑是存储层面的同一个RAID组中有其他业务系统有可能恰好在问题时段有大量的IO操作,
导致我们正在优化的系统的IO延迟较大。跟客户的存储人员确认发现确实如此,存储人员并没有结合数据库对存储做出合理规划,仅仅从容量管理上对自己工作的方便性出发,划分并分配LUN。由此导致性能问题,我想这种问题在很多企业都是存在的,跨部门之间的沟通不畅导致没有从整体上的规划出现,最终出现问题由DB买单。
因此建议客户进行存储改善:
1.将这种关键系统在存储层面与其他系统隔离,避免互相影响IO;
2.有预算的情况下升级存储。
我们通过将性能不佳的业务高峰时段(即问题时段)与性能正常的业务高峰时段(即基线时段)的性能数据进行了对比,发现了一些问题:
基线时段为2014-1-15日上午8:00-上午9:00,此时段TPS(每秒事务量)为:46T/s,该时段的总DB Time为:626.2 (mins)
问题时段为2014-1-20日上午8:00-上午9:00,此时段TPS为:47T/s(仅比基线时段多1T/s,可认为两者业务量相当),该时段的总DB Time为2361.4 (mins)
同样均为1小时的取样时间段,问题段的总DB Time是基线的近4倍,而通过对比两者的性能视图,发现问题时段的单次IO延迟非常高,如下:
Event Waits Time(s) Avg wait (ms) % DB time Wait Class
DB CPU 2,082 55.42
db file sequential read 62,140 774 12 20.61 User I/O
direct path read 177,440 575 3 15.31 User I/O
log file sync 17,486 145 8 3.86 Commit
gc cr block 2-way 98,519 30 0 0.80 Cluster
基线时段单次序列读延时为12ms,单次直接读延时为3ms,单次redolog写延时为8ms,
Event Waits Time(s) Avg wait (ms) % DB time Wait Class
direct path read 180,200 4,643 26 32.77 User I/O
db file sequential read 55,483 2,286 41 16.13 User I/O
DB CPU 1,917 13.53
gc buffer busy acquire 5,513 1,474 267 10.40 Cluster
log file sync 17,541 1,298 74 9.16 Commit
而问题时段单次序列读延时为41ms,单次直接读延时为26ms,单次redolog写延时为74ms
(Oracle文档中建议的单次IO正常延时应为0-20ms,否则需升级硬件),
即相比基线时段,在业务量不变的情况下,问题时段的IO效率下降非常明显,怀疑是存储层面的同一个RAID组中有其他业务系统有可能恰好在问题时段有大量的IO操作,
导致我们正在优化的系统的IO延迟较大。跟客户的存储人员确认发现确实如此,存储人员并没有结合数据库对存储做出合理规划,仅仅从容量管理上对自己工作的方便性出发,划分并分配LUN。由此导致性能问题,我想这种问题在很多企业都是存在的,跨部门之间的沟通不畅导致没有从整体上的规划出现,最终出现问题由DB买单。
因此建议客户进行存储改善:
1.将这种关键系统在存储层面与其他系统隔离,避免互相影响IO;
2.有预算的情况下升级存储。