记一次性能压测

测试团队遇到一个难题：某应用性能压测，在水平扩容后，集群TPS并没有增加。希望排查下具体原因。

症状表现如下：

应用机器为1C1G，k8s负责管理。测试同学在做性能压测时，发现 4副本和10副本的集群总TPS变化不大。

首先对压测方案进行了重新设计：

机型先调整为4C8G。
单副本压测，看瓶颈。
调整机型，再压基线。
集群压测。
数据如下：

单进程、单副本： RT 111ms， TPS 9，CPU占用 2.7C，内存 200M。
双进程、单副本： RT 117ms， TPS 16，CPU占用4.2C，内存300M。
5进程、单副本：RT 169ms，TPS 27，CPU占用5.03C，内存777M。
10进程、单副本：RT 600ms，TPS 15， CPU占用2.76C，内存885M。
6进程、单副本：RT 190ms，TPS 27，CPU占用5.2C，内存910M。
初步分析如下：

因为k8s中设置了动态CPU调整，超出4C时，会动态分配空闲的CPU，所以CPU超出实际要求部分是正常的。内存看起来不是瓶颈，CPU是瓶颈，符合算法服务应用的特性。在10进程的压测结果中，CPU占用下降，TPS 下降，RT上升较多，看起来压力没有传导到实际的应用副本上。从3和5的测试来看，已经是单副本当前性能的极限。所以做以下调整，机型调整为8C8G。

数据如下：

6进程：RT 198ms TPS 30 CPU占用5.3C，内存 819M。
10进程：RT 297ms TPS 33.5 CPU占用5.4C，内存846M。
从结果看，10进程对比6进行没有线性增长。CPU的升配也没有带来性能的进一步提升。做出以下调整：将单副本的线程数由10调整为20。

数据如下：

6进程： RT 192ms TPS 31.8 CPU占用5.2C，内存887M。
可见线程的增加并没有带来显著的提升，应用本身的线程机制也有问题。内存基本无影响，后续不在关注。机型调整为5C2G，单副本的线程数仍改回10。

数据如下：

6进程、单副本：RT 197ms TPS 30 CPU占用5.1C
6进程、双副本：RT 132ms TPS 43.6 CPU占用 <4.5C
12进程、双副本：RT 203ms TPS 60 CPU占用 5C 左右。
60进程、10副本：RT 350ms TPS 172 CPU占用 2C 左右。
从结果可见4中，性能明显下降，猜测可能是网络带宽问题。但是排查了k8s中 ingress (负载均衡)的数据，带宽并没有被打满，而且连接数基本等于压测进程数。开始怀疑是副本所在宿主机的问题。

排查10个副本所在宿主机，发现有4个副本被分配到了两台宿主机(阿里云ECS)上。于是将副本改为8个，保证每个副本都在不同的宿主机上，用之前压测建立的单副本6进程的基线，进行48进程的压测。我们发现 TPS 仍未达到 30 * 8 =240的预期，只有170左右。排查8个副本CPU，发现有数个副本的CPU占用没有到达5C。进一步查看宿主机数据，发现没有达到5C的副本所在的宿主机CPU基本已到了90%以上，基本确定是k8s中CPU超卖导致。

将副本的CPU占用改为独占后，根据实际测试集群空闲CPU的数量，改为 7个副本，压测结果为 RT 200ms , TPS 220 ， CPU占用 基本5C左右。该结果符合我们的预期，确定是CPU超卖导致的压测性能下降，后续进入到应用的性能调优阶段。

本文章已使用新华智云 媒体大脑 区块链版权进行保护。