2022年BOSS数据库系统性能瓶颈分析和定位 .pdf

BOSS 数据库系统性能瓶颈分析和定位内部公开6/29/2007 华为机密，未经许可不得扩散第 1 页,共 10 页BOSS 数据库系统性能瓶颈分析和定位 1 问题描述BOSS 系统月结销账工作涉及到全省移动2000 多万用户帐单费用的计算，并且时间要求非常紧张，必须在每月2 日 1：008：00全部准确完成。因此真正的程序运行时间必须保证在5：00 前执行完毕，以保证有足够的时间核对帐单的准确性。系统自去年 8 月上线以来，一直运行时间保持在23个小时，完全能够保证月结的正常进行，然而最近两个月，在没有更换任何硬件、没有更改任何代码、执行过程中没有出现任何差错的情况下，程序运行越来越慢，大概需要45个小时，这个问题给现场维护组和客户都带来了很大的压力。为此，我们集合了相关各模块维护和开发负责人对系统进行了全面分析和定位。2 初步检查和分析2.1：主机配置检测 uname M -IBM,9119-595 prtconf|grep proc|wc l -56颗 cpu prtconf s -Processor Clock Speed:1656 MHz prtconf m -Memory Size:449280 MB 2.2：机器压力检测 vmstat 2 100 -idle 基本在 3040左右；wio 大概在 1415左右2.3：网络压力检测topas-en0 流量大概在 17M 左右；en1 流量大概 10M 左右2.4：存储压力检测topas-比较繁忙的磁盘大概都在90%左右2.5：应用程序检查 ps ef|grep appserv|wc l -200 余个/节点2.6：数据库检查 2.6.1：检查 v$session，发现数据库连接数为300左右/节点；名师资料总结-精品资料欢迎下载-名师精心整理-第 1 页，共 10 页 -BOSS 数据库系统性能瓶颈分析和定位内部公开6/29/2007 华为机密，未经许可不得扩散第 2 页,共 10 页 2.6.2：检查 undo、system、temp表空间均使用正常；2.6.3：检查 v$session_wait，发现大量 log file sync 等待事件，该现象产生三种猜测，a）：事务提交过于频繁；b）：log_buffer 设置较小，不足以满足目前大型高并发量（200个/节点）的数据库操作；c）：redo log 相关的磁盘 io 存在问题；针对上述三种猜测，我们作了如下的数据搜集工作，并有针对性观察了数据库性能：1）：针对事务提交过于频繁，我们和研发人员作了沟通，他们确认程序是按用户提交的，即一个用户即为一次提交，全省 2000 多万用户，就存在 2000多万提交。2）：针对 log_buffer 参数，我们查看了数据库配置，该参数为20971520，即20M 左右，按照 oracle官方的建议该值已经足够大，继续增加该参数不会有什么改善。3）：针对磁盘 io 瓶颈，我们使用 iostat 命令做了数据搜集，并针对存储 cache，以及光纤通道流量均进行了统计，除发现 io 较高外，没发现其他异常，根据 emc的意见继续加大存储cache不会有太大改善，并且该操作还可能需要业务中断。3 深入分析和定位根据以上初步的检查和分析，我们目前还不能发现数据库配置及数据库外围环境的任何问题，因此，我们决定对数据库作statspack 诊断报告，重点关注数据库中的瓶颈，尤其是应用程序方面的瓶颈。下面对statspack作如下分析：注：红色范围为该 statspack的统计时间。名师资料总结-精品资料欢迎下载-名师精心整理-第 2 页，共 10 页 -BOSS 数据库系统性能瓶颈分析和定位内部公开6/29/2007 华为机密，未经许可不得扩散第 3 页,共 10 页注：Redo size 是指每秒产生的redo log 的多少，该值的高低跟事务量和事务大小有关，该值越大越有可能产生上述“log file sync”等待事件。Transactions 是指每秒产生的事务量，包括 commit、rollback两类，该值的大小主要是跟用户应用有关，该值越大说明系统越繁忙。从上述两项来看，系统很忙，下一步需要确认的是“系统在忙什么？”注：除上述红色事件外，其他性能均较好。Soft Parse 较低说明系统中存在大量的硬解析，该类情况必然导致系统性能下降，但该问题已经定位，不作为本次分析的重点。名师资料总结-精品资料欢迎下载-名师精心整理-第 3 页，共 10 页 -BOSS 数据库系统性能瓶颈分析和定位内部公开6/29/2007 华为机密，未经许可不得扩散第 4 页,共 10 页注：该图说明了系统中等待较为严重的事件，红色部分证明了我们在v$session_wait里看到的系统瓶颈，严重到大量（25877/622275）超时的地步。另外，“db file sequential read”平均等待时间也较高，说明了索引读时磁盘方面存在一些瓶颈，但不严重。注：该图说明了后台事件中等待较长的几个事件，红色部分说明在写db file时存在 IO 等待问题，后续会关注。名师资料总结-精品资料欢迎下载-名师精心整理-第 4 页，共 10 页 -BOSS 数据库系统性能瓶颈分析和定位内部公开6/29/2007 华为机密，未经许可不得扩散第 5 页,共 10 页注：该图显示了逻辑读较多的sql 语句。其中前四个语句来自两个模块，其中 AccSrvpdzw1 是我们正在进行的销账程序，而taskpdbb1是报表统计程序，从逻辑读来看报表的程序不小于帐务的程序。至此，我们立即和报表人员进行了确认，确认了该类程序本应该在月结销账前完成，然而由于业务原因，该程序推迟执行，造成了程序滞后执行，并且该程序也是跟用户相关的程序，该程序的提交同样采用一条一提交的方式，因此大大提交了数据库的事务量，产生了大量的redo log。为了进一步确认，我们继续跟踪了statspack的后续内容。名师资料总结-精品资料欢迎下载-名师精心整理-第 5 页，共 10 页 -BOSS 数据库系统性能瓶颈分析和定位内部公开6/29/2007 华为机密，未经许可不得扩散第 6 页,共 10 页注：该图显示了执行次数较多的sql 语句。其中前四个语句仍然证明了是报表程序加大了系统的符合。经报表人员优化，次月回避了该类程序与销账程序的同时进行，系统性能得到了明显的好转。下面是系统在6 月 2 号的运行报告。名师资料总结-精品资料欢迎下载-名师精心整理-第 6 页，共 10 页 -BOSS 数据库系统性能瓶颈分析和定位内部公开6/29/2007 华为机密，未经许可不得扩散第 7 页,共 10 页注：事务数有了明显降低。Redo size 仍然较大，是由于其他较大事务造成的。名师资料总结-精品资料欢迎下载-名师精心整理-第 7 页，共 10 页 -BOSS 数据库系统性能瓶颈分析和定位内部公开6/29/2007 华为机密，未经许可不得扩散第 8 页,共 10 页注：“log file sync”有了明显好转。注：后台事件基本没有什么长时间的等待。名师资料总结-精品资料欢迎下载-名师精心整理-第 8 页，共 10 页 -BOSS 数据库系统性能瓶颈分析和定位内部公开6/29/2007 华为机密，未经许可不得扩散第 9 页,共 10 页注：从上述表中，可以看出，逻辑读较多的几个语句，均是销账程序的语句，基本达到了我们期望的状况。至此，月结销账过程中数据库性能下降的问题基本名师资料总结-精品资料欢迎下载-名师精心整理-第 9 页，共 10 页 -BOSS 数据库系统性能瓶颈分析和定位内部公开6/29/2007 华为机密，未经许可不得扩散第 10 页,共 10 页得到了解决。4 总结该案例属于日常维护工作中典型的数据库性能问题的分析和定位过程。说明维护人员应该对程序的运行环境非常清楚，尤其是不同系统模块的维护人员在共同维护一套系统的情况下，更需要相互沟通、共同确定自己程序对性能的要求或者可能给系统带来的压力。从另外一个角度来讲，也充分体现了应用优化的重要性。可以说，我们不能只期待着主机或者数据库能够包容所有的应用，而是更应该将自己的应用调到最优以适应实际的运行环境。同时，数据库的优化问题是一项长期和持久的工作，需要不断分析和完善。名师资料总结-精品资料欢迎下载-名师精心整理-第 10 页，共 10 页 -