一次数据库压力测试的故事

Posted 2021-05-02 51Testing软件测试网

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了一次数据库压力测试的故事相关的知识，希望对你有一定的参考价值。

点击上方蓝色字关注我们~

前言

　　最近配合某客户做了一个关于XX系统的压力测试，其实经过和客户的沟通得知，客户此系统上线后压力并不大，但由于应用方前期的表现不是特别尽如人意，对此不太信任，所以要求本次压力测试着重观察。

参与方

　　我、客户、应用方（我和客户简称甲方，应用方简称乙方）

环境配置

　　数据库：RAC一体机集群（为方便统计，应用统一链接一个节点）

　　压测工具：jmeter

压测场景

　　大概10个大场景，每个场景有100、200、300 3个级别的并发小场景，每个小场景压测10分钟

压测数据量

　　压测数据为应用方编造，数据库大小2G，其中涉及的关键业务表数据量大概有40万，10万，3万不等的数据

压力测试

　　此前也做过很多次压力测试，对于数据库方面来说，主要是搜集服务器当时的CPU，内存使用，以及关注AWR报告SQL执行部分是否有异常，便于正式上线后，系统资源的分配，从压测数据量来看，2G数据可以说是很小的数据量，另外并发最大300，对于2G数据来说，也不算大，本以为压力测试可以顺利进行，那也只是理想很丰满。

插曲一

　　在测试其中一个场景A 300并发，jmeter压测工具开始报错（具体报的什么错，暂不追究），乙方给的恢复是数据量太大，达不到300，继续下一个场景 B，100并发，在进行完这个100并发的场景后，就有了如下对话。

　　甲方：xxx表数据上一个场景A 300并发时，还是10万，这个场景B 100并发的场景跑完变成3万条了。

　　乙方（压测人员）：@经理这个我不是很懂，你帮忙看下。

　　乙方（经理）：这个我找人处理的，十万条数据数据量比较大，实际没有那么大的

　　甲方：这在测试呢你们数据清理了？

　　甲方：今天把你们做测试数据的表和对应的数据量都写到方案里确定下来。

　　甲方：不要测试过程中删数据。

　　甲方：不能为了达到并发标准在哪删数据，达不到就是达不到，后期可以优化的。

　　甲方：确定下来测试过程中不要做小动作。

　　乙方（压测人员）：删数据这个我就不知道了，一般压力测试的时候都不会让他们做什么操作的。

　　从上面的对话，大概对情况有一个了解，乙方可能是认为，数据量大所以场景A 300并发报错，在没有和甲方沟通的情况下，私下清理了主业务表数据量，不巧被甲方发现，甲方大为不满。其实压力测试就是为了确认系统的运行压力，如果都和乙方那样，私下清理数据，也就失去了压力测试的实际意义，在此，给各位奋战的DBA 和应用人员一个建议，实事求是，实时沟通。

插曲二

　　由于压力测试，每个大场景都有3个不同并发级别的小场景，但是在分析AWR报告时发现，其中SQL执行次数部分并没有明显的变化，100并发SQL执行次数30000，200并发SQL执行次数30000多，根据以往的压测经验来看，这肯定是有问题的，同时在系统CPU使用来看，也证明了这一点，两个不同级别的并CPU使用并无明显差异，然后甲方乙方开始。

一次数据库压力测试的故事

　　甲方：100和200在数据库后台执行的SQL次数没有太大差别

　　乙方（压测人员）：10分钟100个并发，这么多次；10分钟200个并发，应该不会变成2倍吧。

　　乙方（压测人员）：这个是总次数吧？

　　甲方：是。

　　乙方（压测人员）：那我觉得这个没问题吧？

　　乙方（压测人员）：你说的这个暂时记录着，回头他们看下。

　　乙方（压测人员）：你说的情形，我咨询过了，可能会涉及到修改对应的一个服务里面的参数。

　　乙方（压测人员）：所以今天先100的跑了吧。

　　看到这里，基本明白了，前面几个并发测试等于是白测试了，这也告诉我们，做事还是细致点好，同时要说服乙方，就要拿出证据，免得双方扯皮，怪不得客户提前都说，这次压力测试要着重点看。假如只是为了应付工作，简单的搜集点数据，然后事后再分析，那反工时必然的，吃一堑长一智。

插曲三

　　压力测试终于到了最后3个场景，对于前几个CPU压力表现还算正常，起码是有压力的，但最后3个场景的CPU压力几乎没有，难道是一体机的性能太好？那也不应该，再说这个场景是关于客户分析，市场分析的场景，从字面意思看，应该会访问很多数据表才对，这次又实实在在的分析各个运行的SQL，以及具体涉及的业务表。

　　甲方：上个场景客户分析中 XXXX表是什么表？

　　乙方（压测人员）：我问下去。

　　甲方：那个客户分析的场景数据库服务器几乎没压力后台显示访问比较多的是这张表。

　　乙方（经理）：刚刚那个是地区省份的筛选。

　　甲方：哦客户分析后台的数据来源只有这一个主表么？

　　就在这时，乙方测试人员发了一个哭哭的表情，我就意识到问题有出现了。

　　乙方（压测人员）：你一问，我看了一下。

　　乙方（压测人员）：xx分析的脚本，之前调的时候有部分禁掉了。

　　乙方（压测人员）：重新跑下xx分析吧，我停了。

　　甲方：。。。。。。。。。。。。。。。

　　看来甲方最开始的不信任还是有依据的，这个压力测试在此之前，乙方已经准备了一周左右，但还是出现各种状况。

总结

　　针对此次测试，除了插曲一乙方做的不地道之外，另外2个都是乙方前期准备的问题，在此，我们不对乙方做过于‘积极’的评价。

　　对于我来说，有以下感悟：

　　1、不管是对自己或者客户，做事要以主人公的心态，抱着应付了事，害人害己呀，比如案例中XX方

　　2、和其他环节的人员沟通不确定性问题时，需要拿出确凿证据，免得双方踢皮球

　　3、良好的沟通是客户服务的第一环节，或许你能力暂时不够，但不能糊弄客户，谁都不是傻子。