吐血大放送 RAC 性能调优

[复制链接]
查看11 | 回复9 | 2011-2-18 11:42:49 | 显示全部楼层 |阅读模式
有了本章就可以跟SG的performance tuning说
拜拜~\(≧▽≦)/~啦啦啦~~~~~
本章大部分内容都取自 RAC performance tuning的SG。


这篇文章一开始只是一个人记录 后来转给了朋友 于是变成了如下 有问有答的混合形式了,我想这样也好 ,免得大家看了以后不思考一带而过,于是就把整个邮件保留了下来。
同时也希望大家能帮忙挑挑刺儿 再补充一下其他知识点。


格式略乱 请见谅。

Gc current block 2-way:

1.Sga 1发送请求道SGA2 request blockSGA1产生gc current block request .
2.SGA2检查这个block是否被改变如果已被改变的话LMS则会要求LGWR写redo log(这时SGA1会显示busy)
然后传送。
3.SGA2发送NODE并产生Gc current block 2-way等待直到BLOCK发送到SGA1等待终结。
当发送NODE过程中对这个block的请求将会产生GC buffer busy.

3 way:就是多一个节点resource MASTER和cached节点不是同一个节点。

Lost block :
可能跟OS和网络配置参数相关比如SIDE message比block先到。
减小multiblock read count到16以下可以避免发生这样的事情。

Enqueue Waits :
Enqueue是序列化的

在[url=]RAC[/url]中是全局资源

大多数频繁的等待可能是HW TA SQ TX TM US
这并不是RAC专属但是当应用RAC的时候会出现全局资源锁。
SELECT*FROMgv$enqueue_statisticsWHEREeq_type='TX'
这个视图可以检查各种资源争用的程度。
select*FROMgv$instance_cache_transfer可以知道block级的transfer。

v$segment_statistics
是一个十分有效的用来确定哪个object CR争用特别多的
视图。

--这些都是新知识,
暂时先吸收,提不出什么问题,除了笔误,
大哥,笔误
误人子弟啊
(尤其逻辑上,相反的话)

RAC相关的统计可以分类为:
全局cache service统计:gc cr blocks received ,gc cr block receive time etc..
全局队列service:global enqueue gets and so on.
Message sent:gcs messages sent我擦……
我还不知道这是啥呢……

--这些也是新东西,
不过,貌似白鳝的RAC书上专门列出了一些RAC统计,说的比较详细,可以参考参考

RAC调优Tips:
APPLICATION是最重要的.
重置调整buffer cache的大小(看起来意为缩小
这样可以减少cache fusion {想起来还真惭愧
当初上RAC的时候我还希望能调大cache size只是为了减少使用裸设备后缺失文件系统的影响})

--增加local缓冲区命中率,这样可以减少cache fusion.那不就该加大local buffer cashe?
--首先
如果两个节点数据交互频繁的话
加大缓冲区
意味着
某个table可能在这两个节点中全部被cache住了
,那么当对这个table进行操作的时候
两个节点之间就会进行频繁的通信,减少buffercache可以减轻inter connect上的负担
但是毋庸置疑会增加I/O的负担,(考虑一下吧interconnect上各种锁状态
其实是比从硬盘拿数据时开销大的
但是速度快。)
小的block可以减少cache fusion。我啥时候说过小的block可以减少cache fushion了?
--不是我说你说的, 我是说小的block可以减少cache fusion,因为一个块装的数据少,这样就能降低在同一个BLOCK上的操作。



你的意思是要
减少block的大小还是减少BUFFER CACHE里的buffer的的大小??
还是减少BUFFER CACHE SIZE?
--当然是buffer cache size了
--那就有问题了,到底加大不加大BUFER CACHE SIZE了?(RAC的BUFFER CACHE SIZE不就是指跟个实例的local buffersize?)

不加大Local buffer的命中率的话,
你就会去别的实例搞块。这样也会cache fusion
加大local buffer的命中率的话,不就是加大local的BUFER CACHE SIZE?

我的意思是这样,如果你加大了命中率
那么同时会增加
去别的实例取的几率
了吧?
如果你缩小了
那么会增大硬盘读的机会。


“当初上RAC的时候我还希望能调大cache size只是为了减少使用裸设备后缺失文件系统的影响”
这个是为什么?详细解释一下

n
是这样[url=]linux[/url]系统本身有自己的
文件系统缓存
所以大部分情况下
你看到Free-g命令的返回结果都是free的内存不多
(比如我们128G内存的机器SGA只设置了64G可是free往往只有[url=]10G[/url]左右)
n
这是因为LINUX会缓存你经常使用的文件在内存中
。所以有的时候
你从[url=]ORACLE[/url]中
看到的physical read实际上是从文件系统的缓存中读取的
并不是从物理硬盘中读取的
因为linux替你做了缓存(说的有点复杂
能理解吧)
n
但是由于我们的RAC使用的是裸设备
而linux是无法缓存裸设备的
所以这个时候
需要增大[url=]数据库[/url]的buffer cache来弥补缺失文件系统缓存的影响。
n
当然
裸设备的I/O要比文件系统快得多
--了然
减少大的全表扫描(OLTP)
--这个对OLAP也有用吧?防止被基础local cache..
使用自动段空间[url=]管理[/url](?????)--这个可以理解为减少insert等dml的争用吧?比如INSERT,session会很快的找到合适的block.
如果你使用数据字典管理的段空间的话
数据字典被更新跟block被更新一样
需要在两个节点间传递
你丫自己想想吧。
--这个
我是在回答你的问题,“使用自动段空间管理(?????)”,我以为你丫在问为什么要用自动段空间管理
自动段空间管理部分
当时确实是问号哈
没有时间细想
今天状态好
一想就通了。


谁给我个解释
这句话怎么翻译(我的翻译是ASSM可以使block尽量的粘黏实例)
ASSMcan provide instance affinity to table blocks.
n
这个我也没想通为什么。。得怎么理解。。



增加sequence cache
当sequence用作生成主键时,容易造成索引块的竞争。增大sequence的cache值,有利于减少索引块的竞争,提高leaf block的instance affinity
同时sequence在next的时候如果需要再次获取 则会修改数据字典 同时造成row cache lock.
oracle为了管理sequence使用了以下三种锁
*row cache lock:调用sequence.nextval过程中(nocache)
* SQ锁:调用sequence.nextval过程中(cache+noorder)
* SV锁(dfs lock handel):RAC上节点之间顺序得到保障的的前提下,调用sequence.nextval期间拥有。赋予了cache + order属性的sequence上发生。(cache+order)
创建sequence赋予的cache值较小时,有enq:sq-contention等待增加的趋势。cache的默认缺省值是20.因此创建使用量多 的sequence时,cacheh值应取1000以上的较大值。偶尔一次性同时创建多个会话时,有时发生enq:sq-contention等待事件。 其理由是v$session.audsid列值是利用sequnce创建的,许多会话同时连接时,可以将sys.audses$sequence的cache大小扩大至1000,以此解决enq:sq-contention等待问题。
Rac上创建sequence时,在赋予了cache属性的状态下,若没有赋予order属性,则各节点将会把不同范围的sequence值cache到内存上。
--sequence虽说了解过,
但是你说的还是很有新意,先吸收了。有些疑问,一个sequece放在哪??,每个node用自己的sequece不就得了吗?如果非要争用的话(假设它在shared pool里--还是不明白,每个node不都是有自己的shared pool吗?),
单单就影响索引吗?

Sequence的管理是在数据字典中的
所以同上道理。
--了然
在此处顺便讲解library cache and row cache
这两个东西是global级的东西 所以 如果过度解析的话 那么会增加interconnect的负担。比如说PL/SQL,AQ,recompile package的时候。
---每个实例都有shared pool吧??
这个东西如何在rac里面影响??详细点

哥哥share pool里的数据字典内容都是共享的

。row cache就是数据字典的cache这个是需要两个节点必须同步的。
--能否举个具体例子来?
比如说你某个package对不
两个节点都要用吧
,pin在shared pool里
这个时候
从NODE 2重编译了他,NODE需要同步哇!~
这个时候请顺便考虑 自生成主键(通过一张表记录高低位等方式)的话……这个block就……--这句话再详细点
自生成主键 是依赖于物理table的
频繁的通过更新这个表 来实现序列化
而且这个表很小 往往都是几个block
那你想一下吧……两个节点同时请求获取
更新。
--了然

使用partition。(Hash partition可能会减少buffer busy并且将block分布的更均匀
便于并发访问)
避免不必要的解析
减少锁的使用

减少没必要的索引(因为没必要的索引不但会增加block互相传递的负担
还有索引leaf or brach block分裂所造成的等待)。
还有索引tree太深
的话会对root block
--很新,
很好,先记下


为了避免索引分裂,一个统一,不倾斜的索引结构将是很好的解决办法:
Global [url=]index[/url] partition
增加sequence cache大小。
(打个比方
如果拿到的都是low value的话
会导致反复的修改一个索引的block所以……想想吧。)
--这个不明白
好好解释解释
这个……
我还是当面解释吧
太TM复杂了……
你看看我的索引分裂偏
你就了了
--待续
这个简单说一句
就一句
假设一个索引的block可以放40条记录
如果是number类型的
可能还放个400来条。
默认的sequence是20个
对吧
那么就是说NODE 1拿到20 插入一个block
NODE 2拿到20-40
NODE 2拿到40-60
NODE 1拿到60-80

全部都插入一个block吧?
这个时候就要各种写redo各种传image吧?
了了吧?


Undo Block的思考:

当一个查询视图查看一个active transaction的block的时候
恰好这个block中的内容有多个active的transaction比如说一个table的2行记录被2个instance修改了。
那么就会读取两个instance的undo来merge record。通常发生在更新和查询非常频繁的表上。

解决思路:

短事物

增大sequence来减少索引block的争用
(一样的道理)
在RAC中
远程undo的维护很痛苦。
--上面的问题解释好了
这个我就能懂了吧?(跟sequece XXX,
什么一样的道理?)对
HW - contention:
一般都是插入多了
然后找空闲空间的时候就发生这个:
Enq :HW – contention
Gc current grant
前面的不用解释了就是扩展段
后面的是就是扩展出来的新块
被这个操作需求的时候发生的lock(这个很少会发生争用
毕竟2个insert不会需求相同的块)。

--什么事扩展出来的新块?解释解释这个现象
这个就是说
一旦扩展一个extent里面有8个块
有对这8个新块并发的请求需要
所以产生等待
这个是基本见不到的……
--再详细点,八个新块各用各的
怎么就会征用?
这个我也说不好
脑袋里有一点点感觉
你无视了吧
要么你就帮我解释detail了……
问题不多了,在这里问。

CACHE FUSION优化方面,
不谈应用级别的。

谈系统级的优化,不修改应用。

1如何优化?

rmem_max and wmem_max should be increased beyond 256kb
net.core.rmem_default=262144
net.core.rmem_max=for [url=]11g[/url]: 4194304 ... For 10g: 2097152
net.core.wmem_default=262144
net.core.wmem_max=1048576
_default 确定 socket 在创建的时候分配多少内存给她
_max每个socket 最大消耗内存
2就命中率来说,减少[url=]data[/url] buffer size就一定能减少cache fusion吗?
这个光就命中率来讲不好说,但是减少 databuffer size 确实可减少网络通信 但增加I/O消耗。
3另外还有一个问题
,怎么减少data buffer size?设置较小的sga_target的值?
这样一定会减少DATA BUFFER SIZE吗??
其他的POOL不也减少了?
有cache size.....
回复

使用道具 举报

千问 | 2011-2-18 11:42:49 | 显示全部楼层
这也太乱了点吧!
回复

使用道具 举报

千问 | 2011-2-18 11:42:49 | 显示全部楼层
不知道咋搞的
回复

使用道具 举报

千问 | 2011-2-18 11:42:49 | 显示全部楼层
看得头晕,能不能整理出个文档啊
回复

使用道具 举报

千问 | 2011-2-18 11:42:49 | 显示全部楼层
太乱了。OLTP RAC调优的最佳思路其实很简单,尽量让不同节点访问不同的数据,而且隔离粒度要大,表级别或者分区级别。
回复

使用道具 举报

千问 | 2011-2-18 11:42:49 | 显示全部楼层
顺便把提到的SG发下吧
回复

使用道具 举报

千问 | 2011-2-18 11:42:49 | 显示全部楼层
楼主是帅得乱七八糟,乱得一塌糊涂


回复

使用道具 举报

千问 | 2011-2-18 11:42:49 | 显示全部楼层
原帖由 wolfop 于 2011-5-3 23:30 发表
太乱了。OLTP RAC调优的最佳思路其实很简单,尽量让不同节点访问不同的数据,而且隔离粒度要大,表级别或者分区级别。

wolfop 的话是很对哈,这个是最基本也最复杂的部分。
看来大家对格式抱怨的太厉害了…… 原版本是有颜色区分的…… 发到论坛上就不见了……。 晚上整理一下排版 重发。
回复

使用道具 举报

千问 | 2011-2-18 11:42:49 | 显示全部楼层
楼主,整理一下吧,看着乱。
回复

使用道具 举报

千问 | 2011-2-18 11:42:49 | 显示全部楼层
不过我的博客里 倒是有带颜色的版本哈 等不及的大家 可以先去个人博客瞧一眼。
http://space.itpub.net/?uid-2181 ... space-itemid-694369
回复

使用道具 举报

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

本版积分规则

主题

0

回帖

4882万

积分

论坛元老

Rank: 8Rank: 8

积分
48824836
热门排行