一个分区表,要查反馈统计,count在索引内就可以完成
一开始使用了并行(心想 8cpu + 32 disks array使用并行度四是不是还可以接受?),结果效果太差了,不得不把并行关闭
参考两种情况下的差异,statspack同样采样1小时的周期,虽然压力不一致,但是我们还是可以看到巨大的差异。cpu time 消耗居然相差100倍,faint,都在等待传递并行进程之间的消息了
并行度4下的情况
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
PX Deq: Signal ACK 148,373 2,746 52.02
db file sequential read 448,147 1,294 24.52
CPU time 646 12.25
enqueue 282,946 214 4.06
4,115,030 109,088 37.7 10.0 110.51 1464.13 4226893148
select count(*) from cmnty_user_feedback where to_id = :1 and gm
t_create > :2 and receive_status = 'N' and type < 10
3,426,132 90,852 37.7 8.3 114.79 1147.30 2446752263
select count(*) from cmnty_user_feedback where to_id = :1 and t
ype = 10 and receive_status = :2 and gmt_create >= :3
取消索引上的并行之后
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
db file sequential read 245,789 842 71.21
CPU time 173 14.62
log file sync 154,545 84 7.08
enqueue 1,091 17 1.47
buffer busy waits 5,502 10 .85
-------------------------------------------------------------
844,637 64,408 13.1 4.2 0.98 37.63 4226893148
select count(*) from cmnty_user_feedback where to_id = :1 and gm
t_create > :2 and receive_status = 'N' and type < 10
608,291 46,535 13.1 3.0 0.75 7.02 2446752263
select count(*) from cmnty_user_feedback where to_id = :1 and t
ype = 10 and receive_status = :2 and gmt_create >= :3
取消之后虽然运行次数只有前面的60%,但是 cpu time 从 110多秒变到 1秒以内,总体时间消耗也由1464 秒到 37.63秒。
参考top 5中并行时候生生多了 2,746 秒的等待
对象上的并行度开启要慎重啊