测试团队遇到一个难题：某应用性能压测，在水平扩容后，集群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超卖导致的压测性能下降，后续进入到应用的性能调优阶段。
本文章已使用新华智云 媒体大脑 区块链版权进行保护。
