分享一个解决大量gc等待的案例
这是一个一时手贱改了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个工人了，所以系统又回到了平衡状态。
不错的RAC GC性能分析， cool! 授精！ 嗯，很有启发性。收藏一个。 收藏一个 顶一下！ 学习了！ Maclean Liu(刘相兵 发表于 2014-10-20 12:13 static/image/common/back.gif
不错的RAC GC性能分析， cool! 授精！
最后那个比喻只是我的主观臆测，当时怎么都想不通，又不想把udp的参数改回去，因为overflow的值确实是一直都在增加，且累计值也很大，不知道真实的情况是不是oracle真的是如此运作的。 已经收入我的笔记 谢谢 支持，谢谢分享，长知识了！
页:
[1]