ORACLE TUNE THINKING (三) 操作系统优化

作者简介：

----------------------------------------------------------------------

@ 孙显鹏，海天起点oracle技术专家，十年从业经验

@ 精通oracle内部原理，擅长调优和解决疑难问题

@ 致力于帮助客户解决生产中的问题，提高生产效率。

@ 爱好：书法，周易，中医。微信：sunyunyi_sun

@ 易曰：精义入神，以致用也！

@ 调优乃燮理阴阳何其难也！

----------------------------------------------------------------------

概述：

任何软件都是运行在操作系统上，如果底层操作系统出现性能问题对运行在其上面的软件影响是极大的。比如操作系统的IO架构存在问题或者物理内存严重不足导致应用IO读写延迟高，

大量换页操作消耗更多的IO资源，高的IO延迟又影响了内存换页操作，大量的上下文切换消耗CPU资源。不健康的操作系统上运行任何软件都是效率低下的。ORACLE也不例外。我们主

要从三个大的方面对操作系统进行评估，CPU，MEM,IO。那么如何评估呢？那就需要数据，需要借助工具收集数据和量化数据。这里我们以nmon为例讲述如何分析三大指标。

(关于nmon工具的安装使用方法大家自己学习，因为我只能教给你思想，至于具体的操作还希望大家多动手练习。做什么事情都是一样的，不能纸上谈兵。我在培训时候经常遇到

有的同学讲自己听的很明白了，可是实际遇到问题还是不会处理，技术一定要自己动手操作，不做实验那是不行的)。

CPU部分：

01.png (73.59 KB, 下载次数: 252)

2018-7-31 17:14 上传

这个图是一天的系统负载采集图

如果CPU使用率非常高，需要确定是谁导致了CPU高。需要关注cpu 平均使用率和最大使用率，是User%占比例高还是Sys%占比高还是Wait%占比高呢？

l SYS部分比例高那就需要确定是否硬件资源不足还是其他问题导致系统部分CPU过高。

l User部分高确定是哪个业务用户高，比如oracle部分占比高，哪个进程的问题，结合oracle报告分析，latch问题？硬解析问题？还是目前硬件资源不足？

l Wait部分高一般来讲可能存在大量等待IO操作，需要分析IO问题

IO部分：

02.png (267.64 KB, 下载次数: 229)

2018-7-31 17:14 上传

IO 指标需要分析IOPS(每秒IO操作次数)和吞吐量(每秒的IO读写大小)。这两个指标相互影响，如果IOPS高会导致吞吐量降低，反过来吞吐量很大IOPS就会降低。那么到底怎么样才算合理呢？前提是不要超过IO系统的瓶颈，对于很繁忙的OLTP系统高的IOPS也许是正常的，对于OLAP系统需要高的吞吐量。这个是启望值也是我们优化的目标。但是实际可能遇到复杂的问题，比如过度索引引起高IOPS，大量小文件操作引起高IOPS等导致系统IO繁忙不能高效工作。

图表描述了整个系统IO运行状况。首先解析下该图：

蓝色表示 每秒读 单位：KB/S

橙色表示 每秒写 单位：KB/S

黑色表示 每秒操作IO的次数单位：IO/S

21点到08点，系统读写较大，高峰值达到300KKB/S，这个值较高，说明IO吞吐量很大，该段时间系统在做备份操作。08点到20点，系统IO操作次数也就是IOPS很高，

当然高的IOPS导致低的吞吐量了。频繁的小IO导致了大量的IO操作次数必然导致系统处理能力下降。经过分析发现系统需要上传备份到其他系统，这应该是引起IOPS高的原因。

从下面oracle对IO的收集信息可以明确看到ORACLE对数据文件的操作IOPS贡献很小：StatisticTotalper Secondper Trans

physical read total IO requests9,584,636666.0547.83

physical write total IO requests1,542,516107.197.70

ORACLE在工作时间贡献的IOPS大约为900，那么从nmon系统层面看到了IOPS峰值达到了6600左右，这个值是非常高的。也就是说明系统层面引起了大量的io操作，

导致IO层面非常的繁忙，进而导致了oracle数据库在请求IO时出现部分等待事件。

看看存在IO问题系统TOP 等待

03.png (21.64 KB, 下载次数: 222)

2018-7-31 17:14 上传

ORALCE给出的经验值平均IO等待时间20ms以下是合理的，当前大多数存储是可以满足该指标。上面采样数据显示IO等待太高。需结合操作系统IO数据和存储厂商的分析数据深入

分析IO层面哪里存在瓶颈。

处理方法建议：

1：优化SQL，消除不必要IO操作。

2：条件允许下隔离生产库的raid组。

3：购买SSD作为raid组单独存放热数据。

4：使用ASM技术。

5：优化磁盘访问方式，比如只存储数据在磁盘外道。

内存部分：

04.png (199.54 KB, 下载次数: 230)

2018-7-31 17:14 上传

上图描述了操作系统物理内存剩余大小，几乎没有可用物理内存供操作系统调用。那么没有物理内存可用会发生什么？大多数操作系统的内存管理都是相似的，每个进程有自己的虚拟寻址空间，

当物理内存不足进程使用时，操作系统依据替换page算法将最近不使用的page交换出物理内存写入磁盘(交换空间)，我们知道内存读写速度相对磁盘是非常快的，IO操作是系统代价最高操作。我们忽略page置换导致的上文切换继而产生的CPU资源，只考虑IO性能，磁盘读取数据代价是非常大的。系统目前物理可用内存几乎为0，那么就导致了大量的使用交换空间，性能会急剧下降。AIX在换页空间用完时会kill进程，这是非常严重的。

处理方法建议：

1：检查系统参数是否合理设置，是否存在bug(特别是AIX系统)。

2：购买新内存。

3：降低SGA大小给操作系统预留足够内存。

总结：

本章主要从三个重要指标讲述了操作系统层面优化思路，讲述了CPU,IO,内存三部分优化分析思路，提供了对应的优化方案。为什么操作系统优化列在优化最前面呢？

因为操作系统高效工作是保证运行在其上面软件能高效运行的必要条件。有时候我们经常会忽略检查操作系统是否配置合理，数据库存在性能问题或者故障，就一门心思分析AWR、ASH。

就比如中医治疗外感同时内虚寒，这时候你不要管外感问题，应当首先调理内虚寒，内虚寒好了外感自然也就好了。治病有先后顺序，外感病如果因为身体内部存虚寒你再怎么治疗外感那是

不起作用的。同样的底层操作系统出现问题了你只关注oracle数据库的问题那是不会有什么效果的。你比如到客户现场巡检也好处理故障也好，第一首选应该检查操作系统日志，确保底层

没有故障，然后再看oracle相关指标。这都是经验，大家一定要注意。当然了操作系统优化方法不只是这三个方面，比如很重要的参数调整，这个希望部署数据库时依据oracle官方给出的

建议结合实际情况调整即可。其他细节方面比如io调度策略，大页内存(透明大页内存)，缓存解析，io队列深度等等吧遇到问题依据oracle建议和各厂家建议调整。优化调整一定要有依据，

不能随便自己想。