黄远邦：生产比测试慢？应用程序行为与服务器配置之间的性能关系

前言：马上要迎来2018年了，技术人生系列文章也已经来到了五十期，过去五十期你都有读过了吗？有收获吗？新的一年我们将继续分享我们再数据中心的故事，期待大家继续一同分享。

今天的故事又是来自一个压力测试的问题，同样的SQL语句为什么在生产环境和压测环境的效率不一致呢？是服务器的配置不一致？我们应该如何评估呢？我们来看看今天的分享。

问题来了

某客户发现生产库上的跑批脚本经常跑了180+ 分钟，而在测试库跑完脚本只要60分钟；客户觉得生产服务器的配置比测试服务器高，而且数据库的压力很小，出现这种生产比测试还慢的情况无法理喻，怀疑是ORACLE数据库有问题，所以联系小编进一步排查。

负载性能

先看生产库的AWR，面对这种数据库总体性能问题，从AWR入手可以直观而且全面地了解一个数据库的性能和问题；

生产库运行在AIX平台上8C 32GB，操作系统配备了8个CPU，数据库DBTime为1个自然时间，DB CPU为0.7个自然时间，该库负载正常。其他各项负载指标（内存命中率，每秒的逻辑读、数据变化、物理读写、用户调用数、解析数、事务数等等）都正常且从中看出数据库压力很低。

从等待事件上看，DB CPU占了76%的DB time，其他IO类等待都属于正常范围。

看看TOP SQL部分，按Elapsed Time排序

可以看到所有执行次数高的SQL语句平均执行时间都在100~300毫秒，几乎时间都花在CPU上，执行效率杠杠的！！

相关知识科普：

一个SQL乃至整个DB在的时间消耗组成：CPU、等待，会话进程要么处于等待资源的状态（IO、Concurrency、Commit、NETWORK等），要么就是跑在CPU上或等待OS CPU。一个系统的DB CPU所占的DB Time比例越大，某种程度上说明系统性能越好，因为等待和争用资源的时间少，真正使用CPU干活的时间多了。

总而言之，该库没有明显的性能问题，为什么用户会觉得就是慢了？

资源消耗上看问题

其实对比测试库的AWR就能发现问题了，每种类型的语句单次执行时间上，生产库都比测试库多花了几十上百毫秒，这就是跑批比测试库慢的直接原因。

对比看出生产库的SQL执行过程中消耗在CPU上的比例较大，普遍在90%左右，而测试库仅占了50%左右，可以定位到两者执行时间的差异体现在CPU处理时间的差异。在下图的CPU Time上可以得到验证，生产库上的跑批SQL单次执行的CPU Time普通超过100毫秒，而测试库上仅用了几十毫秒。

生产库CPU Time：

测试库CPU Time：

排除干扰项，我们仅取执行量最高的语句b0fw8rk517gnp进行具体分析，以下是AWR中的SQL性能统计。

生产库：

测试库：

从上述对比两个环境中，执行计划一致，逻辑读相当的情况下（8000+），可以大致认为数据库执行SQL所处理的工作方式和工作量一致；但消耗在CPU的时间却相差较大，生产库平均用时260+毫秒，测试库平均用时70+毫秒。换言之，比起测试库，生产库的CPU性能较差，需要花更多的时间去处理相同的工作量。

可能有人想说，一个库的负载这么低，生产库SQL的执行速度这么快，真的会因为一点点时间差距发生这么大问题吗？

相关知识科普：

在串列程序上几十毫秒的差别足可以导致程序完成延误几个小时。在核心系统上，有时候单个语句的轻微性能变差就能让交易堆积，更甚者会话暴涨，连接池爆满，应用崩溃。所以，在性能问题上有时候就是这么锱铢必较。

如何验证？

生产库CPU信息：

测试库CPU信息：

两者都是8个CPU，不过生产库CPU是POWER 6，处理主频是3504 MHz，测试库CPU是POWER 7处理主频是4088MHz。嗯，看来确实是由于CPU性能比不上测试库。

通过ASH数据分析，碰巧大部分时间都仅有1个会话处于活跃状态，而且调用的SQL语句就是执行次数最多的b0fw8rk517gnp。嗯，从历史会话执行情况了来看确实程序主要是串列的。

将这一结论告知客户，确认程序就是串列的，那么足可以说明CPU性能差异下的SQL执行效率的微小差异导致程序整个执行时间被放大。答案就是这样了？

客户并不这么认为，因为系统管理员告诉他生产库的CPU是绝对比测试库性能好的，测试库的CPU是通过VIOS虚拟化的，其实只分配了1个物理CPU，而生产库是4个物理CPU共8核。

这个回答我一时不知作何回答，大脑停顿了2秒。既然如此就只能拿出强有力的证据，我说等我一下证明给你看看吧。

下面用具体的实际测试用例，来证明CPU到底哪个强？

经过设计的测试中，两个环境执行计划一致，对一个小表做了两次TABLE ACCESS FULL，并在内存中对其结果进行HASH JOIN。总共52个逻辑读，没有物理读，也就是排除了IO等待等其他因素，几乎所有时间都花在了CPU（或等待OS CPU）进行表关联时的hash join匹配上。完成相同的任务基础上测试库用了7.6秒，生产库用了15秒，用时多了接近一半！可以得证生产服务器的CPU性能表现确实比测试服务器的要差！

这份结果让客户信服了，但是这就可以下定论为CPU配置的差距吗，生产库的CPU真的比不上测试库的CPU么？不对，或者说只是在这种特定程序行为和压力负载不高的场景下才出现这样的现象。

延伸思考

测试库配置了怎么样的CPU策略暂不深究，咱们思考的是：如果一个服务器仅有2核CPU高处理主频，另一个服务器有8核CPU稍弱处理主频，在不同场景下的性能效果哪个更强，难道整机配置高表现就一定更好吗？

还是用前面的测试案例，分别在两个不同CPU配置的环境下，使用noparallel、parallel的运行方式对比两者的执行性能，测试机器为8C 1502 MHz VS 2C1900 MHz，展示结果为稳定测试结果。

Noparallel 执行计划：

Noparallel mpstat：

Parallel 4+4执行计划：

SQL> select COUNT(*) from t1 a,t1b

where a.c1=b.c1 and a.c2=b.c2 and a.c3=b.c3 anda.c4=b.c4;

Parallel 4+4 mpstat：

测试总结：

使用非并行执行计划时，配置2C1900 MHz比8C 1502 MHz快；

当使用并行执行计划时，配置8C1502 MHz比2C 1900 MHz快；

一个非并行执行计划是单线程的，操作系统通常分配一个CPU进行工作；一个并行执行计划是多线程的，操作系统根据资源调度策略分配多个CPU进行工作。

相关知识科普：

CPU调度不是一成不变的，CPU资源的分配还要根据不同操作系统的CPU调度而定，举个特殊的例子：HP-UX上使用SCHED_NOAGE策略来解决分时调度策略带来的CPU分配问题，如果没有设置SCHED_NOAGE则可能导致使用CPU严重的oracle进程被降低CPU资源优先级，操作系统上获取不到CPU则oracle进程会一直处于ONCPU状态不干活，资源无法及时释放便会影响数据库性能。

以上例子从侧面说明，能否充分发挥整机CPU的综合性能，还要看具体情况下ORACLE服务器的会话并发量和负载压力有没有到达一个度，而应用程序的调用方式也能直接影响ORACLE服务器的工作方式和负载状况。

换句话说，整机性能的强弱与不同场景下的性能强弱是没有绝对关系的，当单核能应对的场景下，也许一颗CPU就能干得赢多颗CPU。