oracle-数据库性能优化操作系统


上海 Oracle 用户组 -- SHOUG -- ShangHai Oracle Users Group http://www.shoug.info/ ORACLE 数据库性能优化操 作系统资源检查步骤 by SHOUG. 周亮 上海 Oracle 用户组 -- SHOUG -- ShangHai Oracle Users Group http://www.shoug.info/ How to Find SHOUG?  上海 Oracle 用户组 -- SHOUG -- ShangHai Oracle Users Group http://www.shoug.info/ 检查操作系统资源 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 http://www.shoug.info/  交换空间大小。交换空间不足,可能会引起系统 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 http://www.shoug.info/ “木桶效应”指的是一个由许多块长短不同的木板箍成的木桶,决定其容水量大小的并非是 其中最长的那块木板或全部木板长度的平均值,而是取决于最短的那块木板。要想提高木桶 容量的整体效应,不是增加最长那块木板的长度,而是下功夫补齐最短的那块木板的长度。 同样,一套典型的 I/O 系统有多个组件组成,一旦某个组件发生性能问题,则会影响到整个 I/O 系统的性能。所以在设计 I/O 系统时,需要考虑到“木桶效应”。各个组件的 I/O 吞吐 量如表 7-1 所示(需要注意的是硬件更新换代非常迅速,以下指标仅供参考)。 图 7-1 各 I/O 组件的性能指标 组件 理论指标 最大吞吐量 (Bytes/s) HBA 1/2 Gbit/s 100/200 Mbytes/s 16 Port Switch 8X2 Gbit/s 1600 Mbytes/s Fibre Channel 2 Gbit/s 200 Mbytes/s Disk Controller 2 Gbit/s 200 Mbytes/s GigE NIC 2 Gbit/s 80 Mbytes/s Infiniband 1 Gbit/s 890 Mbytes/s CPU 10 Gbit/s 200-250 MB/s 1.4 查看网络资源 网络资源的好坏通常用延迟(Latency)、带宽(Bandwidth)和冲突(Collisions)等指标来表 示。延迟指的是数据包在发送端到接收端所经过的时间,单位为 ms。在内部网络中,延迟应该在 1ms 以 内。带宽指的是在单位时间内所能传输的数据量。在千兆网络环境下的 ftp 实际传输速度应该维持在 80MB 左右。冲突指的是接受者和发送者在同一时间发送包导致包冲突。和主机的 CPU 资源、内存资源、 I/O 资源相比,网络资源则显得宽裕很多。一般来讲网络故障通常是由硬件问题引起的,所以出现故障的 概率也相对比较低。主要表现为网络延迟或者网络丢包。当网络出现故障时主要检查以下环节:  网络交换机故障。  主机网卡故障。  Windows 环境中的病毒。  传输大文件导致网络堵塞。  大量的并发短连接导致监听繁忙。 上海 Oracle 用户组 -- SHOUG -- ShangHai Oracle Users Group http://www.shoug.info/ 在 RAC 环境中,私有网络环境的好坏直接影响到数据库的高效运行。在单节点环境中,网络环境主 要影响数据在客户端和服务器端的传输效率,传输效率变慢时将导致 SQL 语句执行速度变慢,从而加大 数据库死锁的概率。 作者个人简介 周亮 个人微博:http://www.weibo.com/dbathinker 《Oracle DBA 实战攻略:运维管理、诊断优化、高可用与最佳实践》一书作者。目前已定稿,2013 年 6 月份出 版。 杭州美创科技 Oracle 技术服务团队负责人,Oracle 10g OCM。精通 Oracle 数据库原理。拥专职 Oracle 数据库管 理经验,对于数据库架构设计、运维、调优、排故有着丰富的实战经验,擅长在极端环境下进行数据库灾难挽救。 上海 Oracle 用户组 -- SHOUG -- ShangHai Oracle Users Group http://www.shoug.info/ 带领 Oracle 技术服务团队,为公司客户提供上百套数据库维护工作。其中涉及政府、通信、金融、公安、电力、交 通、医疗、制造等行业。主要工作内容有:日常运维、故障诊断、性能优化、容灾实施、灾难挽救、系统割接、恢 复测试、数据迁移、业务上线护航、Oracle 技术培训、解决方案提供、7*24 小时电话或远程支持等工作。 熟悉 AIX,HP-UX,SOLARIS,LINUX 等主流操作系统平台,熟悉主流存储卷组管理。 在各种场合下多次主讲 Oracle 10g OCP/OCM 培训课程、案例分析课程。
还剩6页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 10 金币 [ 分享pdf获得金币 ] 0 人已下载

下载pdf

pdf贡献者

buffon1005

贡献于2016-05-25

下载需要 10 金币 [金币充值 ]
亲,您也可以通过 分享原创pdf 来获得金币奖励!
下载pdf