ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 吐血大放送 RAC 性能调优

吐血大放送 RAC 性能调优

原创 Linux操作系统 作者:flying_warrior 时间:2011-05-03 21:28:03 0 删除 编辑

有了本章就可以跟SG performance tuning( ^_^ )/~~拜拜~\(≧▽≦)/~啦啦啦~~~~~

这篇文章一开始只是一个人记录 后来转给了朋友 于是变成了如下 有问有答的混合形式了。格式略乱 请见谅。

 

Gc current block 2-way:

 

1.Sga 1 发送请求道SGA2 request block  SGA1 产生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 是序列化的

                 RAC 中是全局资源

                         大多数频繁的等待可能是 HW TA SQ TX TM US

这并不是RAC专属 但是当应用RAC的时候会出现全局资源锁。

SELECT * FROM gv$enqueue_statistics WHERE eq_type='TX' 这个视图可以检查各种资源争用的程度。

select * FROM gv$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 sentgcs 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了?(RACBUFFER CACHE SIZE不就是指跟个实例的local buffersize?

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

      加大local buffer的命中率的话,不就是加大localBUFER CACHE SIZE

 

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

如果你缩小了  那么会增大硬盘读的机会。

 

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

n  是这样 linux 系统本身有自己的 文件系统缓存  所以大部分情况下 你看到 Free  -g 命令的返回结果都是 free 的内存不多 (比如我们128G内存的机器 SGA 只设置了64G 可是free 往往只有10G左右)

n  这是因为LINUX 会缓存你经常使用的文件在内存中 。所以有的时候 你从ORACLE 看到的physical read 实际上是从文件系统的缓存中读取的 并不是从物理硬盘中读取的 因为linux 替你做了缓存(说的有点复杂  能理解吧)

n  但是由于我们的RAC 使用的是裸设备  linux 是无法缓存裸设备的  所以这个时候 需要增大数据库的buffer cache 来弥补缺失文件系统缓存的影响。 

n  当然 裸设备的I/O 要比文件系统快得多

--了然

减少大的全表扫描(OLTP

--这个对OLAP也有用吧?防止被基础local cache..

使用自动段空间管理(?????)--这个可以理解为减少insertdml的争用吧?比如INSERT,session会很快的找到合适的block.

如果你使用数据字典管理的段空间的话    数据字典被更新跟block被更新一样 需要在两个节点间传递  你丫自己想想吧。

--这个 我是在回答你的问题,“使用自动段空间管理(?????)”, 我以为你丫在问为什么要用自动段空间管理

自动段空间管理部分 当时确实是问号哈 没有时间细想 今天状态好 一想就通了。

 

 

谁给我个解释 这句话怎么翻译(我的翻译是  ASSM 可以使block 尽量的粘黏实例)

ASSM  can provide instance affinity to table blocks.

n  这个我也没想通为什么。。得怎么理解。。

 

 

增加sequence cache

sequence用作生成主键时,容易造成索引块的竞争。增大sequencecache值,有利于减少索引块的竞争,提高leaf blockinstance 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属性,则各节点将会把不同范围的sequencecache到内存上。

--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 index 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 transactionblock的时候 恰好这个block中的内容有多个activetransaction 比如说一个table2行记录被2instance 修改了。  那么就会读取两个instanceundo merge record。通常发生在更新和查询非常频繁的表上。

 

解决思路:

      短事物

      增大sequence 来减少索引block的争用 (一样的道理)

RAC 远程undo的维护很痛苦。

--上面的问题解释好了 这个我就能懂了吧?(跟sequece XXX 什么一样的道理?)

HW - contention

一般都是插入多了 然后找空闲空间的时候就发生这个:

Enq :HW – contention

Gc current grant

前面的不用解释了就是扩展段  后面的是就是扩展出来的新块 被这个操作需求的时候发生的lock(这个很少会发生争用 毕竟2insert 不会需求相同的块)。

 

--什么事扩展出来的新块?解释解释这个现象

这个就是说 一旦扩展一个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 11g: 4194304 ... For 10g: 2097152
net.core.wmem_default=262144
net.core.wmem_max=1048576

 _default 确定 socket 在创建的时候分配多少内存给她

 _max每个socket 最大消耗内存

2 就命中率来说,减少data buffer size就一定能减少cache fusion吗?

 这个光就命中率来讲不好说,但是减少 databuffer size 确实可减少网络通信 但增加I/O消耗。

3 另外还有一个问题 ,怎么减少data buffer size? 设置较小的sga_target的值? 这样一定会减少DATA BUFFER SIZE吗?? 其他的POOL 不也减少了?

 有cache size.....


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/21818314/viewspace-694369/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2009-06-21

  • 博文量
    49
  • 访问量
    78942