ORACLE 数据库性能优化操作系统资源检查步骤by SHOUG. 周亮 上海Oracle 用户组 -- SHOUG --ShangHai Oracle Users Group /How to Find SHOUG? 上海Oracle 用户组 -- SHOUG --ShangHai Oracle Users Group / 检查操作系统资源Oracle 数据库的性能依赖于其所在的硬件和操作系统的性能。因此，诊断性能问题时，应将操作系 统资源指标视为整体性能指标的一部分。CPU、内存、I/O 是既相互独立又相互关联的三大操作系统资 源。一般来讲，增大数据库的SGA 会增加CPU 的消耗，降低存储的I/O 性能会释放部分CPU 资源。 1.1 查看CPU 资源CPU 资源是否紧张可通过检查CPU 的利用率及等待运行的进程数量来了解。CPU 的运算 速度主要受主频（Processor Clock Speed）高低和缓存（Cache Memory）大小影响。比如 说，在高并发的OLTP 系统中，由于每个CPU 在特定时间内只允许一个进程运行，所以这里 的CPU 个数决定着事务的运行效率；而在OLAP 系统中，由于并发进程不高，但运行时间较 长，所以CPU 的主频决定着事务运行效率。
在很多DBA 眼中，CPU 的资源使用率往往是评价性能的唯一指标（认为CPU 利用率越低 越好），其实这个观点是错误，因为合理并最大程度地利用系统资源是数据库优化的目标之 一。举个简单的例子。在大型超市中，如果只开放一个收费窗口，顾客肯定要排很长的队， 收费效率会很低下，但员工的总体空闲率却很低。既然设置了那么多收费窗口，并相应配备 了员工，那为什么不开放所有的收费窗口来提高收费速度呢？但是当顾客很多时，即使开放 了所有收费窗口，由于每位员工的收费速度有限（服务时间有限），顾客依然会排长队（等 待时间长）。在这种情况下，要缩短排队时间，只能通过增加收费窗口来解决。从系统层面 来讲，这种情况则为真正达到了CPU 资源的瓶颈。从经验上讲，当vmstat 命令输出中的r 队列 （等待运行的进程数量）数量长时间超过2 倍系统的CPU 核数时（暂且不论引起等待队 列过高的原因），系统的CPU 资源肯定会紧张。 1.2 查看内存资源内存资源是否紧张主要检查操作系统是否有交换产生。主机的内存资源主要分物理内存 和交换空间（虚拟内存）两块。当进程需要新的内存资源，而实际内存资源不足的时候，系 统会把部分活动性弱的内存数据写入交换空间，在进程需要的时候再次从交换空间中读出。
为提高Oracle 运行性能，则要求没有进程 （计算性内存，即SGA）被交换到交换空间。很多DBA 简单地认为只要将数据全部放在内存中，或者设置BUFFER CACHE 的大小大于 数据库就会提高数据库性能。事实上，大内存并不能保证数据库系统的性能就很优良。虽然 数据块的BUFFER CACHE 命中率为100%，但并不能保证SQL 的运行效率高。提高SQL 运行效 率的优化思路是降低SQL 的逻辑读取数据块数量。内存一直是数据库性能优化时的重点优 化对象，内存分配没有多或少之分，够用就行。当系统内存不足时，可能会产生大量的内存 交换。出现此类现象时，主要检查以下内容： 上海Oracle 用户组 -- SHOUG --ShangHai Oracle Users Group / 交换空间大小。交换空间不足，可能会引起系统HANG。 操作系统虚拟内存参数，如AIX 系统中的maxclient%和maxperm%参数，设置过高可能会导致非计算型内存占用过高。 Oracle SGA 参数的设置。过大的SGA 参数设置往往会产生系统内存交换。比如系统内存为32GB，SGA_MAX_SIZE 参数设置为28GB，这样的系统极容易产生交换。
是否存在大量的异常进程。异常进程主要表现在进程没有及时退出导致数量过多、进程内存泄露两方面。 1.3 查看I/O 资源虽然硬件厂商在过去的10 年中，一直在努力地通过各种办法加强I/0 吞吐量，但是I/O 操作仍然是计算机中最慢的活动。存储I/O 能力的高低通常用吞吐量、IOPS （I/O Per Second 即每秒进行I/O 操作的次数）、磁盘响应时间等指标来表示。决定存储性能的主要 因素在于存储阵列的算法、Cache 命中率，以及磁盘数、存储I/O 总线的宽度。Cache 的命 中率取决于Cache 的算法、Cache size 的大小、以及数据的访问规则。一般情况下，Cache 的读命中率越高，支持的IOPS 也就越高。每个物理硬盘能处理的IOPS 是有限制的，一张 15K 转的SATA 物理盘以8/2 比例混合读写时，理论上能达到160个左右的IOPS。实践表 明，当磁盘的服务时间（avserv 值）超过20ms 或者等待时间（avwait 值）大于0 时，存储 的响应可能会出现问题。存储的I/O 响应缓慢往往是由以下因素引起的： 当应用所发起的IOPS 超过物理盘的理论IOPS 时，系统的I/O 能力将急剧下降。
热点盘。即数据访问集中在几张盘上。 系统大量交换导致本地盘繁忙。 不合理的RAID 配置模式。 存储性能瓶颈。主要表现为控制器不足或者I/O 通道堵塞。 异步I/O 配置问题。如maxreqs 参数配置过小等。 磁盘队列深度不足。如操作系统参数queue_depth 配置过小。 磁盘转速较低。 硬件故障。存储的 CACHE 故障，主要表现为 CACHE 失效、CACHE 算法有问题从而致命中率不高。如果CACHE 保存的数据能够命中，I/O 的响应时间一般可以缩短在1ms 以内。 提示 不要迷信存储厂商的IOPS （每秒的io 数）数据，这些数据可能是在全部在CACHE 命中的基础上实 现的，但是实际上，你的cache 命中率可能只有10%。 上海Oracle 用户组 -- SHOUG --ShangHai Oracle Users Group / “木桶效应”指的是一个由许多块长短不同的木板箍成的木桶，决定其容水量大小的并非是 其中最长的那块木板或全部木板长度的平均值，而是取决于最短的那块木板。要想提高木桶 容量的整体效应，不是增加最长那块木板的长度，而是下功夫补齐最短的那块木板的长度。
同样，一套典型的I/O 系统有多个组件组成，一旦某个组件发生性能问题，则会影响到整个 I/O 系统的性能。所以在设计I/O 系统时，需要考虑到“木桶效应”。各个组件的I/O 吞吐 量如表7-1所示（需要注意的是硬件更新换代非常迅速，以下指标仅供参考）。 图7-1 各I/O 组件的性能指标 组件理论指标最大吞吐量（Bytes/s） HBA1/2 Gbit/s100/200 Mbytes/s 16 Port Switch8X2 Gbit/s1600 Mbytes/s Fibre Channel2 Gbit/s200 Mbytes/s Disk Controller2 Gbit/s200 Mbytes/s GigE NIC2 Gbit/s80 Mbytes/s Infiniband1 Gbit/s890 Mbytes/s CPU10 Gbit/s200-250 MB/s 1.4 查看网络资源网络资源的好坏通常用延迟（Latency ）、带宽（Bandwidth ）和冲突（Collisions ）等指标来表 示。延迟指的是数据包在发送端到接收端所经过的时间，单位为 ms。
在内部网络中，延迟应该在 1ms 以 内。带宽指的是在单位时间内所能传输的数据量。在千兆网络环境下的 ftp 实际传输速度应该维持在 80MB 左右。冲突指的是接受者和发送者在同一时间发送包导致包冲突。和主机的 CPU 资源、内存资源、 I/O 资源相比，网络资源则显得宽裕很多。一般来讲网络故障通常是由硬件问题引起的，所以出现故障的 概率也相对比较低。主要表现为网络延迟或者网络丢包。当网络出现故障时主要检查以下环节： 网络交换机故障。 主机网卡故障。 Windows 环境中的病毒。 传输大文件导致网络堵塞。 大量的并发短连接导致监听繁忙。 上海Oracle 用户组 -- SHOUG --ShangHai Oracle Users Group /在 RAC 环境中，私有网络环境的好坏直接影响到数据库的高效运行。在单节点环境中，网络环境主 要影响数据在客户端和服务器端的传输效率，传输效率变慢时将导致 SQL 语句执行速度变慢，从而加大 数据库死锁的概率。作者个人简介 周亮 个人微博：/dbathinker 《Oracle DBA 实战攻略：运维管理、诊断优化、高可用与最佳实践》一书作者。目前已定稿，2013 年6 月份出 版。 杭州美创科技Oracle 技术服务团队负责人，Oracle 10g OCM。精通Oracle 数据库原理。拥专职Oracle 数据库管 理经验，对于数据库架构设计、运维、调优、排故有着丰富的实战经验，擅长在极端环境下进行数据库
