Oracle数据库数据恢复、性能优化来问问AskMaclean - ParnassusData诗檀软件旗下网站

找回密码
注册
搜索
热搜: 活动 交友 discuz
发新帖

0

积分

0

好友

2

主题
发表于 2014-10-20 11:26:52 | 查看: 5362| 回复: 8
这是一个一时手贱改了aix系统参数引起的故障,但是就算现在解决以后还是有点想不通其中的缘由,写出来大家一起参详一下。
软件环境:oracle 11.2.0.3 rac
硬件环境:ibm两台小机p750,p550,内存均为32G,p750 8颗4核CPU,p550  8颗2核CPU,操作系统均为aix 6.1
平时情况:AAS基本也就在0.2 左右,awr top 5的等待事件主要为DB CPU,要占到50%-60%,其他有db file sequential read,
log file sync,direct path read等,系统运行基本正常。

9月初在网上看到一篇关于db_file_multiblock_read_count,db_block_size以及操作系统udp_recvspace,udp_sendspace参数之间的帖子,说道了
1、设置udp_sendspace >=[(DB_BLOCK_SIZE * DB_FILE_MULTIBLOCK_READ_COUNT) + 4096],但是不低于 65536.
  比如,DB_BLOCK_SIZE=8192, DB_FILE_MULTIBLOCK_READ_COUNT=16,那么udp_sendspace>= (8192 * 16) + 4096=135168.注意这个值只是最低值,并不是Oracle要求必须设置这么大。
2、设置udp_recvspace 为 4到10倍 udp_sendpace
3、由于sb_max 必须 >= udp_recvspaceIf ,可能需要增加sb_max的值(默认为1048576)

http://feed.askmaclean.com/archives/category/udp_recvspace 这篇文件还挺广泛的,我看了自己机器上的overflow,发现非常大,而且udp_sendspace、udp_recvspace也是默认值65536,655360于是就按照 以上规则进行了修改。

完成后的几周awr 很多gc等待,而且rac相关的几个参数全部超标
Avg global cache cr block receive time (ms): 198.7
Avg global cache current block receive time (ms): 3.6
Avg message sent queue time (ms): 3,160.3

sent queue都3秒多了,前台业务系统变慢。

这期间我观察过机器上的overflow(执行 netstat -s | grep "socket buffer overflows")发现还是在增加,后来找到这篇
http://www.askmaclean.com/archives/differ-gcs_server_processes-gc-cr-multi-block-request.html
查看我的-gcs_server_processes参数,发现p750是3,p550是2,这是根据oracle的算法,自动设定的默认值一直没有改,
参数gcs_server_processes的计算方法:
If 1 - 3 CPUS, then 1

If 4 - 15 CPUs, then 2

If 16 or more CPUs, then 2 + (CPUs / 32). If the result includes a fraction, then the fraction is disregarded. For example, if you had 20 CPUs, then 2 + (20 / 32) would equal 2 GCS processes.

If CLUSTER_DATABASE is set to false, then 0

If ASM, then 1

oracle把750认作存在32个cpu,550认作存在16个cpu。

根据官方文档,rac中不同实例可以有不同的gcs_server_processes,最关键的是,我之前就是不同的,但是awr并没有显示相关的性能上的问题,gc的几个指标也完全正常,为什么改了udp的接受发送缓存大小反而会引发这个问题呢?

这个问题一直拖到国庆,我修改参数,重启实例(这个是初始化参数),然后惴惴不安的等着上班后观察情况,节后上班,连续观察到现在,gc事件完全消失(没有出现在top 5中了),Avg global cache cr block receive time (ms): ,Avg global cache current block receive time (ms),Avg message sent queue time (ms)也完全正常了只有0点几ms了,而且之前的消息发送是这样的:
% of direct sent messages: 1.90
% of indirect sent messages: 39.98
% of flow controlled messages: 58.13


修改后:
% of direct sent messages: 82.77
% of indirect sent messages: 17.12
% of flow controlled messages: 0.11

完全反过来了。

另外udp溢出的值也不再增加(aix中几个网络统计都是累计值,要看其增加量,或者清零后再观察)

根据网上的资料,RAC 11.2.0.3中gcs_server_processes不同时应该存在bug。但是我的情况是:原来就不同却并没有引发这不bug,一直到修改了aix的udp参数才导致了这个问题。

我有个不恰当的比方:

一条河两岸,原来一边有3个工人,每人能搬砖5块,对岸有2个工人,每人也能搬砖5块,但是摆渡的船只能一次运10块砖头,虽然第三个工人的砖老是掉水里(缓存溢出),但是项目进度很宽松并不要求一次一定要运输10块以上,而那些掉水里的砖就由工人自己捡起来重新运(系统的溢出重传),所以也相安无事。
后来,摆渡船的能力增加了,一次可以运输15块(udp缓存区增加了),对岸2个工人就吃力了,常常无法让渡船按时返回(造成了各类gc等待,各种超时)。
再后来,两边都是3个工人了,所以系统又回到了平衡状态。




发表于 2014-10-20 12:13:53
不错的RAC GC性能分析, cool! 授精!

回复 显示全部楼层 道具 举报

发表于 2014-10-20 12:20:15
嗯,很有启发性。收藏一个。

回复 显示全部楼层 道具 举报

发表于 2014-10-20 13:25:50
收藏一个

回复 显示全部楼层 道具 举报

发表于 2014-10-20 14:01:01
顶一下!

回复 显示全部楼层 道具 举报

发表于 2014-10-20 14:21:50
学习了!

回复 显示全部楼层 道具 举报

发表于 2014-10-20 19:39:15
Maclean Liu(刘相兵 发表于 2014-10-20 12:13
不错的RAC GC性能分析, cool! 授精!

最后那个比喻只是我的主观臆测,当时怎么都想不通,又不想把udp的参数改回去,因为overflow的值确实是一直都在增加,且累计值也很大,不知道真实的情况是不是oracle真的是如此运作的。

回复 显示全部楼层 道具 举报

发表于 2015-1-13 21:54:47
已经收入我的笔记 谢谢

回复 显示全部楼层 道具 举报

发表于 2015-1-14 12:17:54
支持,谢谢分享,长知识了!

回复 显示全部楼层 道具 举报

您需要登录后才可以回帖 登录 | 注册

QQ|手机版|Archiver|Oracle数据库数据恢复、性能优化来问问AskMaclean - ParnassusData诗檀软件旗下网站

GMT+8, 2022-1-17 03:07 , Processed in 0.047951 second(s), 21 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部
TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569