降低lms进程数量oracle,案例诊断：如何打破RAC性能瓶颈？

Oracle  Real  Application  Clusters  (RAC) 是一个共享缓存的集群数据库架构，它突破了传统的无共享和共享磁盘架构的限制，从而能够提供无与伦比的数据库高可用、可伸缩性和可靠性，而且无需对现有的 Oracle 数据库应用程序进行修改。

我们在享受RAC业务连续性、高可用性、可伸缩性优势的同时，往往会因为其架构复杂造成应用性能瓶颈，本篇将着重介绍数据是如何在RAC架构中实现同步转移，各个进程如何协作实现一致性等，了解其中原理，最后我们将通过何种方式去跟踪分析性能瓶颈根结，找到治本的解决方法。

▏概念一览▏

▲缓存一致性

● 在一个实例中有多个缓冲区高速缓存(buffer cache)，并且ORACLE RAC是采用共享一切的体系结构的。

●缓存一致性是为保持数据库的一致性。

●只有一个实例能在当前独占模式(exclusive current mode)下持有一个块。并且这个块只有在这个状态下才能被修改。

●可以有两个待处理的事务同时修改相同的块，但这个块只能在一个实例中以独占模式被持有。

▲单块读

如果缓冲块不是在本地缓冲区高速缓存中，进程将在这个块头上找到其所属的主节点。然后这个进程会通过心跳网络发送一个请求给此块的主节点上的lms进程。

当发送这个请求时，其并不知道这个块现在存在于哪个实例上。直到LMS响应前，用户进程会等待一个”占位符”的等待事件，诸如gc cr read, gc current read等。

在从LMS进程接收到响应后，之后的时间会被累计到相应的其他等待事件中。如果此块不在任何实例的高速缓存区中，则LMS进程将在这个资源上赋予PR(保护读)模式的锁，并让FG(前台进程)从磁盘上去读取。

FG – Foreground Process(前台进程)

LMD – Lock Manager Daemon(锁管理守护进程)

GRD – Global Resource Directory(全局资源目录)

PR – Protected Read(保护读)

【举个例子】

◐ 以下的跟踪文件显示这个会话等待的是一个2-way grant等待事件，其次是一个磁盘读。

◐ 在从磁盘读取块前，实例先得到了保护读(PR)模式的锁。

▲单块传输

●如果在远程实例的缓存处于一个兼容模式，则LMS进程会赋予其一个锁。

●远端的LMS进程传输块给前台进程。

●前台进程将这个缓存复制到高速缓冲区。

●拥有该块的实例将会在这个块上获得一个锁(CR块传输不更新GRD)。

●你可以看到的GC事件，但GC事件之后不会有关于disk磁盘的事件。

▲GCS(Global Cache Service)结构

▲三段单块传输(Single block transfer -3 way)

块在实例3的高速缓存区中，实例2是这个资源的目录实例(directory instance)。LMS进程通过心跳网络从实例3传输块。

▲GRD

在传输之后,GRD更新块的所属，这两个实例都是此块的所有者。

如果块以PR(保护读)模式从一个实例转移到另一个实例，那么这个块的模式被认为是当前模式传输(current mode transfer)。随后，’gc current blocks received’ 统计增加。

▲修改缓存

在修改一个缓存块前，这个缓存块必须以独占模式(Exclusive mode (EX))获得BL锁。

如果这个缓存块已经存在于他的高速缓冲区内，其他实例将会从他们高速缓冲区降级或者刷出这个块。当某个实例以EX模式获得了这个缓存块，则其他实例将会从buffercache中刷出这个块。

▲繁忙度

gc cr block busy, gc current block busy事件表明这些块处于繁忙状态。在这个情况下，这个块是以EX模式存在于另一个实例中，LMS进程申请重做块(undo block)去实现块的一致性，这个块为cr模式的的缓存块。

过多的*busy事件表明应用关联度不好。关联的应用将可以减少这些*busy的等待事件，因为关联的应用会将这些块放在同一个实例中修改。

▲Gcs log flush sync

但如果在缓存块已经传输到其他节点后，发生了实例崩溃，那RAC怎么去维护其一致性呢？

其实，在发送一个当前模式(current mode)块前，LMS进程将会请求LGWR进程去执行一次日志刷出。直到LGWR进程发送一个返回信号给lms进程，这段期间，lms进程都会等待“gcs log flush”事件。

果块被认为在“忙”，则CR块传输可能需要刷新日志。被认为繁忙的条件之一是这个块是通过申请undo(回滚)记录构造的。

▲CUR模式

如果两个实例同时修改一个块，但是是这个块的不同行，会发生什么情况？

行级别锁会阻止两个不同的实例去更新相同的行。在一个实例能修改一个块前，这个实例必须在缓存中获得EX模式的锁。没有两个实例可以持有EX模式和兼容的缓冲状态的块。

如果有两个未决的事务，并且来自不同的实例去修改同一个块会发生什么？没有两个实例允许同时持有EX模式GCS锁得xcur模式的缓存。

▏RAC等待事件 ▏

一、数据包的类型

▲块类的数据包：

●Consistent Read blocks

●Current Read blocks

▲消息类的数据包

●Single block grants

●Multi block grants

▲服务类的数据包

●SCN generation

●Row cache updates

●GES layer packets

▲Cr 等待事件

以下是与cr模式传输有关的最多的等待事件：

1.没有阻塞或并发的传输：

gc cr block 2-way

gc cr block 3-way

2.多块读：

gc cr multi block request

3.并发相关

gc cr block busy

gc buffer busy (acquire/release)

4.授权：

gc cr grant 2-way

5.阻塞相关：

gc cr grant congested

gc cr block congested

▲Gc cr block 2/3-way

●‘gc cr block 2-way’ 统计的时间为，这个块的所有者和其属组在一个实例的活动。

●如果所有者不在主实例(master 实例)，则等待事件为3-way。

●如果没有其他额外的工作，如创建CR块或争用，则时间统计这些等待事件。

【分析】

●‘gc cr block 2-way’ 和 ‘gc cr block 3-way’ 事件可以被认为是校对cache fusion性能的基线事件。

●一般来说，有并发或拥塞的问题是没有这些事件的。

▏案例:平均等待时间较高 ▏

▲如果时间等待直方图显示这些事件较高，则可能因为：

1 这个节点有高的CPU使用，导致进程无法足够快的得到cpu。

2 网络性能或网络配置问题。

3 SMP缩放或NUMA相关的平台问题。

●由于并发或拥塞等待是没有考虑到这些等待，这些都是很好的基线缓存融合性能指标。

▲诊断

用脚本event_histogram.sql查看事件直方图：

(在下面这个例子中，等待了2-4ms的占41％。)

▲建议

●保持cpu使用率在80%-85%以下。超过80%的cpu使用率，就会产生调度效率低下并且多重的缓存融合(cache fusion)性能问题。

●可能考虑巨型帧。巨型帧减少组装和拆装的数据包，所以会稍微降低CPU使用率。

●用OS工具重新检查网络性能。

●如果有cache fusion流量拥堵，检查私有专用互联。

●检查cache fusion 拥堵是否和其他网络拥堵有关

▏案例2 ：这两个事件的过量等待 ▏

◐如果有巨量的这个等待事件的等待，找到对象和引起这些等待的SQL.

◐SQL trace 或ash能帮助识别和这些等待事件相关的对象。

◐ASH数据是一个采样数据，所以要注意采样量是否足够。

◐Sql trace中的object_id同样能够找到对象。

▲诊断

引起这些等待的最高的对象：

▲建议

●考虑应用程序的关联度，数量庞大的块在实例间来回传输，表明解决应用程序的关联性将会有很大帮助。

●对于这个工作量，SGA的大小可能偏小，试着增加sga大小是一种选择。

●集群将因为两个点之间网络的延时而遭受更长的延时。

▲Gc cr block congested(拥挤)/gc cr grants congested

这些等待事件表明，有CPU资源匮乏问题：

●例如，突然产生的PQ进程会导致cpu 负载，并使得cpu紧张。

●通过sql语句的调优减少cpu的使用率，计划性的job在不同的时间运行，或根据需要增加新节点。

●在实际繁忙的环境中，会有许多等待事件，只有在awr或sqltrace显示对这些事件有大量的等待时间，我们才会去关注。

▲Gc cr grants 2-way

如果该块不在缓冲区高速缓存的。这个等待事件统计得到授权后，从磁盘拿到缓存区这段时间。

这段trace 显示这个等待时间在一个磁盘读前，

一般的延时为1-2ms。进程发送一个请求给远端主LMS进程，然后LMS进程简单的回复一条”read from disk”信息。这是另一种基线测量(interconnect)互连的响应时间的等待事件，是有限的LMS处理。

▏诊断总结 ▏

ORACLE RAC是目前市面上真正唯一做到并行模式的集群，RAC的所有集群成员都可以同时接收客户端请求，这样我们将能使用较低廉的服务器来实现高可用性、高吞吐量的集群环境，这要比通过对某台高端服务器增加硬件实现高可用性、高吞吐量花费的成本低很多。

▲RAC存在的问题

虽然RAC有非常多的优点，但由于部署一套RAC会涉及服务器、存储设备、HBA卡、操作系统等多方面的技术，且从实现上要比单实例数据库更复杂，对硬件设备的稳定性、设备之间以及设备与操作系统的兼容性上要求也更高，Oracle的bug也会造成RAC运行出现问题。

所以，从实际的运行情况来看，RAC要比单实例的数据库存在更多的问题，问题的原因也各不相同。

性能是大部分从单机环境迁移到RAC环境比较头疼的问题。在目前普遍使用千兆网 络的硬件环境中，很多时候系统的数据库从原来的单机迁移至RAC环境，系统的性能反而下降。

在这种情况下，数据库管理员应该根据RAC的特点对系统调整提出合理的建议，经过合理的设计、开发，使用RAC是能够提高系统的处理性能的。

通过本篇略窥门径，希望大家能理解RAC架构内部工作原理，更好的找到根结原因，提升性能。

——本文为笔者参照外文原著

《advanced rac troubleshooting》

并结合自身观点所写——