高并发insert影响tps(每秒事务数)诊断

和客户一起做一个高并发insert的测试,使用的软件是loadrunner.我们会对分区表的两个分区进行大量的insert操作.模拟一些售票的情况.这个测试的过程长达1个多小时,要保障我们的tps(每秒事务数)在5000以上.结果运行了两次,均在35分钟左右的时间点tps降到3000以下,持续时间2-3分钟.通过ash报告,我发现在tps下降的过程中出现下列问题.

Slot Time (Duration) Slot Count Event Event Count % Event
19:37:00    (0 secs) 196 log file sync 171 0.22
CPU + Wait for CPU 19 0.02
buffer busy waits 2 0.00
19:37:00   (1.0 min) 12,023 log file sync 10,948 13.92
CPU + Wait for CPU 662 0.84
latch: library cache lock 103 0.13
19:38:00   (1.0 min) 10,367 log file sync 8,826 11.23
CPU + Wait for CPU 617 0.78
enq: HW – contention 463 0.59
19:39:00   (1.0 min) 16,145 latch: cache buffers chains 14,519 18.47
log file sync 866 1.10
CPU + Wait for CPU 421 0.54
19:40:00   (1.0 min) 15,882 latch: cache buffers chains 8,815 11.21
log file sync 6,263 7.97
CPU + Wait for CPU 551 0.70
19:41:00   (1.0 min) 12,926 log file sync 11,889 15.12
CPU + Wait for CPU 623 0.79
latch: library cache 88 0.11
19:42:00   (1.0 min) 11,083 log file sync 9,609 12.22
CPU + Wait for CPU 567 0.72
cursor: pin S 181 0.23

注意观察在19点38分钟的时候出现了enq:HW – contention之后,就开始出现很高的latch:cache buffers chains.正好在这段时间里面tps下降到了3000,那么这究竟是一个什么原因呢?
首先我们看看enq:HW-contention,这个等待事件是Oracle在高水位线的争用等待,当在执行insert语句的时候,高水位线以下的block不够用了,此时Oracle会推进高水位线,并进行格式化block的操作.同时insert操作还在继续,此时oracle会把刚刚扩展的block读入到SGA中,此时block header放入到hash chain上.大部分insert都对这个新的块进行操作,需要获取到latch,导致latch:cache buffers chains的等待升高.从而导致insert的tps下降.知道这个产生的原因之后,我们对这个segment进行了allocate extent的预分配后,重新用loadrunner跑了一遍,tps就没有在下降了,一直保持在5000以上.

分享到: 更多

Post a Comment

Your email is never published nor shared. Required fields are marked *