0 积分	0 好友	1 主题

发消息

[常规总体性能调优] rac 极短时间内的性能问题可能阻塞/并发争用引起的

1^#

发表于 2013-11-7 16:53:10 | 查看: 4570| 回复: 7

本帖最后由无为而为于 2013-11-11 15:31 编辑

各位好，感谢刘和各位进贴。

环境：rhel5.6x86-64 系统，ibm3850主机，emcvnx5500存储，数据库为10.2.0.5.0 64bit RAC
(详细awr,ash见附件)
现象：8点左右从中间件上发现短时处理积压。

诊断：

8点到8点15分这段时间内发生as积压，从ash来看，比较明显的可以看到是因为gcbuffer等待引起的

08:06:00 (6.0 min)	194	gc buffer busy	184	64.11
		CPU + Wait for CPU	7	2.44

SQL ID	Planhash	% Activity	Event	% Event	SQL Text
xxx	394901286	55.05	gc buffer busy	54.70	UPDATE ARBICONTRACT A SET A.LE...

从相关来看，比较明显的就是如下sql引起的gc buffer busy的等待
UPDATE ARBICONTRACT A SET A.LEG_NUM =:B8 , A.ARBI_STATUS =:B7 , A.FUTU_PRICE_STEP=:B6 , A.HIGH_LIMIT_PRICE =:B5 , A.LOW_LIMIT_PRICE =:B4 WHERE A.FUTU_EXCH_TYPE=:B3 AND A.ARBICONTRACT_ID=:B2 AND A.ARBICODE=:B1

gc buffer busy 等待在RAC中非常常见了，我们应用系统也针对GC做过优化，即根据不同用户分节点连接。ARBICONTRACT表的用户符合我们程序配置规范，所有相关全连在发生积压的第一节点，并且并未在node2上发现ARBICONTRACT表的相关查询。

进一步来看node1上top5
Event       Waits       Time(s)       Avg Wait(ms)       % Total Call Time       Wait Class
gc buffer busy       2,047       157       77       77.0       Cluster
CPU time                44                21.6
log file sync       14,832       11       1       5.2       Commit
reliable message       270       10       36       4.8       Other
control file sequential read       18,771       5       0       2.7       System I/O

可以看到除了gcbuffer的等待，还有大量log file sync等待，这个等待和redolog写入磁盘有关，即写redo慢。

从全局enqueue来看：

Statistic	Total	per Second	per Trans
acks for commit broadcast(actual)	108	0.03	0.01
acks for commit broadcast(logical)	116	0.03	0.01
broadcast msgs on commit(actual)	12,957	3.60	0.70
broadcast msgs on commit(logical)	12,970	3.60	0.70
broadcast msgs on commit(wasted)	246	0.07	0.01
broadcast on commit wait time(ms)	84,616,149	23,515.04	4,586.99

这里broadcast on commit wait time等待相当惊人。第二节点上gcs log flush sync 平均等待为4ms，说明私有网络也有些偏慢

查看node2上top5

Event	Waits	Time(s)	Avg Wait(ms)	% Total Call Time	Wait Class
control file sequential read	758,090	141	0	83.1	System I/O
CPU time		82		48.1
gcs log flush sync	2,091	8	4	4.4	Other
control file parallel write	3,017	2	1	1.2	System I/O
enq: CF - contention	1,238	0	0	.2	Other

发现关于控制文件的等待很大，还出现了enq: CF - contention，这个是controlfile阻塞的锁。其会阻塞lgwr写。

故我推测：

1 由于控制文件发生争用，阻塞了第二节点lgwr写入磁盘，而此时第一节点的update操作会广播同步（也就是我们看到的broadcast on commit等待），第二节点lgrw写入发生困难，故导致第一节点同步有问题，进而产生大量gcbufferbusy的等待（也就是我们看到的表像）。

2 我怀疑是rman备份的方式,有没有可能是因为备份未删除过期备份记录，归档记录等。导致控制文件被涨的很大等引起的。

3 从第二节点flushlog来看，平均等待有4ms，这个时间偏长。私有网络是否有问题我还在查。

请指教。谢谢

分享0