综合因素导致Exadata性能下降

个人简介:石云华,Exadata中国用户组联合创始人,2019年被ORACLE官方授予ACE称号。毕业后一直从事Oracle数据库第三方运维服务工作,拥有十余年电信运营商、保险、税务、电力行业核心系统数据库运维经验。现就职于北京海天起点技术服务股份有限公司,oracle数据库专家组成员,Exadata部门负责人。个人著作有《Exadata实施运维指南》,另外一本《Oracle Exadata性能优化》即将面世。

案例概要:

我们曾经服务过的一个Exadata客户,有一台1/4配置高性能盘的Exadata X2-2,上面运行了一套混合型的Oracle数据库,据现场服务的同事反馈,这套数据库经历过多次性能问题。

案例分析及处理:

第一个性能问题,整个操作系统的响应都非常缓慢,任意一个操作系统级别的命令,例如:ps、ls等都需要很长时间才返回结果,通过Exadata上自带的oswatcher工具收集了经历性能问题时操作系统的资源使用情况,如下信息为oswatcher工具中vmstat命令收集的内容。

从以上收集的信息可以看出,SI和SO都非常高,同时SY列在短时间内出现100%左右,说明操作系统出现的性能问题是由于进行了大量的页交换导致的。

如下信息为oswatcher工具中ps命令收集的内容。

从ps命令收集的信息可以看出,系统中没有异常的进程占用大量的虚拟内存,基本上全是数据库的服务进程和数据库中的并行进程占用虚拟内存。这基本上可以说明是由于数据库自身占用内存太多,导致需要进行页交换而引发的性能问题。

收集exachk工具的输出报告,查看计算节点的hugepage配置情况,具体信息如下所示。

从exachk工具的输出报告可以看出,该计算节点未配置hugepage。

继续检查该数据库的内存设置情况,具体命令如下。

从以上收集的信息可以看出,SGA和PGA一共将近分配了70GB的内存,而X2-2的Exadata,数据库服务器上只有96GB的物理内存。这样的数据库内存配置明显偏高,需要减少SGA和PGA设置。

这套数据库上第2个次性能问题是CPU使用率动辄80%以上,同时并行进程大量地队列等待。在大多情况下,系统负载比较高,当并行进程达到100左右时,CPU使用率已经接近90%,如图10.13所示,在出现并行和CPU性能问题时的TOP5 等待事件。

图10.13 AWR报告中的TOP 10等待事件部分

系统压力较大时,CPU使用率非常高,具体如图10.14所示。

图10.14 AWR报告中的CPU使用信息

从图10.14可以看出,数据库主机的CPU压力非常大,已高达90%左右,峰值时接近100%。

检查消耗CPU较多的SQL语句情况,如图10.15所示。

图10.15 AWR报告中消耗CPU最多的SQL语句

抽取其中的某一条SQL语句并格式化处理后,SQL语句基本上雷同,具体的SQL语句如下所示。

这种SQL语句,简单看上去就存在两个缺陷:① 为了数据加工而生成的临时表,竟然使用了混合列压缩方式。本来这个数据库系统的CPU压力就已经非常大,这种处理方式对CPU而言只会是雪上加霜。② 并行hint竟然使用了/*+ parallel (24) */的方式。这种并行hint方式的SQL语句,在数据库级别开启再多的并行度,也能被这种SQL语句瞬间消耗光。并行hint的这两种语法/*+ parallel (24) */和/*+ parallel (a,24) */具体的区别在哪?简单来说,就是如果第一种方式会对SQL语句中涉及的每一张表对象都会开启24个并行,例如某SQL语句中涉及3张表的关联,则第一种hint方式会对该SQL语句开启72个并行会话;而第二种hint方式只会对具体指定的表开启24个并行会话。作者重新编辑:② 并行hint指定了24个并发,而SQL语句的并发度并不是越高越好,需要考虑到整个系统的资源使用情况。当前系统的CPU压力非常大,所以需要减少并行hint中指定的并发数。 上述被删除的这段话中,并行度所派生出的并行子进程算法有误,没有经过认证,就简单地以单表指定parallel的算法来错误地推导出多表关联时的parallel算法,十分抱歉,二者的算法区别还是非常巨大的。经过测试发现,在11g环境中如果多表关联的SQL语句,仍然希望使用并行hint时,还是推荐使用/*+ parallel(n) */方式,它比/*+ parallel(a,n) */方式简单、高效。

后来跟开发人员聊起”为什么在生成的临时表上使用混合列压缩方式?”这个问题时,答案竟然是因为存储空间不够,他们也没有办法,只能”饮鸩止渴”。继续检查该Exadata的存储容量使用情况,具体命令如下。

从上面的输出可以看出,usable_file_mb都已经是负数,说明存放在上面的数据已经极不安全,同时,DATA_DM01磁盘组的可用空间只有200多GB。

查看存储节点IO相关的资源使用情况,cell01存储节点的IO信息通过脚本收集的具体内容如下所示。

同样,cell02和cell03存储节点的IO信息通过脚本收集的具体内容也大体类似,可以看出IO的读写平均延时都非常高。

查看OSWatcher工具收集的存储节点iostat命令输出信息,具体内容如下所示。

从上面的IOstat资源使用情况来看, Exadata的IO使用率已经在80%多,IO的等待时间远高于服务时间,说明该Exadata的IO资源也接近饱和。

从以上CPU、内存和IO各方面收集的信息可以看出,该Exadata上的数据库目前在CPU、内存和IO方面都面临重大的性能问题。

案例解决方案:

基于该Exadata上的数据库存在的种种性能问题,最终给客户的解决方案如下:

第一阶段:先解决内存问题。

  • 减少数据库中SGA和PGA的内存使用量。
  • 操作系统层面设置hugepages。
  • 修改操作系统的内核参数:

第二阶段:再解决存储容量和IO性能问题

  • 物理上扩容存储节点。
  • 对历史表或历史分区(不进行DML操作的对象),进行EHCC压缩归档。
  • 开启索引监控,对系统中未使用的index,首先置于invisible状态,确认对系统没有影响后,删除invisible的索引。

当然,物理上扩容存储节点是最直接并且行而有效的办法,第2和3种方式工作量太大,并且并不一定有理想的效果。

第三阶段:最后解决CPU和并行问题。

  • 改写SQL语句中的并行hint,不要使用parallel(n)的方式,同时将并行度降至2。
  • 改写SQL语句,将数据加工的临时表的混合列压缩方式去掉。

很可惜,由于多方面的原因,这个客户还没开始实施这些优化建议就着手废弃了这台1/4配的X2-2,以上提出的优化建议也无法看到最终的效果了。

未经允许不得转载:Oracle一体机用户组 » 综合因素导致Exadata性能下降

相关推荐