和客户一起做一个高并发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