在虚拟机上容器环境性能--动态测试问题分析总结（二）

在上一篇中，介绍了静态测试场景，本文介绍动态性能测试的差异分析，希望大家可以借鉴。

动态测试模型和结果：

相同的调用链，相同的软件配置，虚拟机核数和内存更多，性能反而更差。

过程分析：

首先基于客户的测试结果，虚拟机更高的规格，反而测试效果不如物理机。虽然并不是大部分应用都是纵向扩展后，性能更高，有的与应用的类型，应用特点，多核特性等多方面有关系，因此还是需要基于此结果给一个客观的对比。

因此分析和对比过程主要如下：

1.测试环境物理配置对比：

2.测试环境上软件环境差异对比：

2.1操作系统内核对比

①Uname查看内核信息：

物理机信息：

[root@ns-yun-020046 ~]# uname –a

Linux ns-yun-020046.vclound.com 3.10.0-862.el7.x86_64 #1 SMP Fri Apr 20 16:44:24 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

对应CVM信息：

结论内核版本都是3.1，差异不大。

2.2Java启动参数配置对比：

Java启动参数，包括堆栈内存分配大小基本一致。

2.3使用Perf Top命令查看物理机和虚拟机上的配置对比：

其中对比分析后，发信主要的差异是在perf top命令下，raw_spin_unlock_irq这个物理机和虚拟机存在较大差异，通过和内核同学，以及参考网上的介绍分析，初步判定，应用在处理互斥同步过程中，有大量的线程等待以及进程上下文切换，影响了性能。https://www.cnblogs.com/aaronLinux/p/5890924.html

由于上述只是一个初步猜测，没有证实最终原因，同时在不断测试过程中发现另外两个奇怪现象，如下：

1）CPU利用率跑满：

压测过程中，OSP1所在的容器中Java进程的CPU利用率持续在400%（top命令查看， CPU的资源分布到多个CVM的核上）

2）OSP1所在CVM上的线程会达到2000多个

3）Perf top命令看到热点函数调用情况，_raw_spin_unlock_irqrestore占据了超过10%

基于上述情况，更改了虚拟机的规格，重新部署该容器应用，进行了多个样本测试：

基于前面硬件环境，软件环境对比，以及多样本测试对比可以得到几个现象和结论：

• 应用之间是否存在耦合，和客户交流，客户的应用之间采用服务注册和发现，组件使用的是zookeeper，服务每次重启会自动注册到zookeeper，服务调用方初次调用访问ZK，获取应用的地址，缓存到内存，因此Zookeeper不是性能的卡点。
• 首先查看各个容器节点（OSP2，OSP1，OSPProxy）中应用的行为和访问，查看各个节点CPU，内存，IO上的瓶颈，发现同样是4C8G容器，OSP1 CPU利用率400%，调整其它两个节点，性能提升不大，但是提升OSP1 CPU核数，性能提升明显，证明：测试性能的瓶颈在OSP1节点的CPU。

• 调整容器的网络为host network模式，性能提升没多大变化，网络性能不是关键因素。
• 调整OSP1节点所在CVM节点的类型，提升CVM性能，因此将CVM由S2（56C224G）调整为S3（80C320G），S3相比S2 CPU更强，核数更多，发现性能基本没提升，证明：对于OSP1节点而言，宿主机核数越多并不能提升性能。
• 从应用角度查看到，压测状态下，有大量的Java线程，线程数量和物理机上有倍数差距，怀疑压测状态下，OSP1根据核数来生成一定的java线程。

排查思路和分析结论：

⑤根据CPU使用率最高的进程查看系统的性能损耗，发现大部分的CPU时间按照线程分布，都消耗在futex上，由第四步可以看出，java线程的CPU调度到了CVM 56个核上，并且根据futex的解释，初步判定OSP这个程序系统线程之间存在信息的同步和资源竞争，导致大量的时间在futex等待，上锁和解锁中，如果线程越多，核数越多，性能反而降低。

⑥同时通过strace –p跟踪osp的java进程，可以看到线程之间存在futex锁等待，导致CPU并不能完全用来处理压测业务，很多CPU实际处于空转状态。

因此初步结论：

CVM CPU越多，并不能提升性能，因为OSP程序生成的Java线程的CPU调度到多个核上，多个线程在争抢futex锁，不是CPU越多越好。因此改进测试状况验证推断：

1）将容器的核绑定到某些固定CPU。

2）创建一个和物理机相同核数的CVM验证测试。

基于前面结论，进行了优化测试，用来进一步佐证分析结论：

优化测试场景一：将容器的核绑定到某些固定CPU

测试改进说明：

基于K8S的策略，调整容器的CPU绑定策略，在OSP1节点，调整kubelet服务，将CPU静态绑定-feature-gates=CPUManager=true --cpu-manager-policy=static

最终结果：

如上表所示，同样56核调整以后，性能提升到13kQPS。绑核之后的情况，User使用率上升了，futex系统调用下降了

优化测试场景二：创建一个和物理机相同核数的CVM验证测试

测试改进说明：

将OSP1所在CVM的规格调整到和物理机类似，24核。

最终结果：

如上表所示，同样56核调整以后，性能提升到13.5kQPS，没有绑核操作，性能大幅提升，证明OSP应用，与核数确实有关系。如果核数越多，容器的CPU调度到多个CVM的核上，造成资源的切换损耗，同时，由于OSP多个线程之间存在同步，核数越多，线程越多，存在的futex等待越多，CPU处于空耗。

①使用和物理机相同规格的CVM实例来部署应用，例如S2 24核48G；优先推荐腾讯云系列3的实例，例如标准型S3和计算型C3，CPU性能更好，价格并没有增长。

②推荐按照优化建议，重新测试一下在腾讯云上的性能。

③在物理机上，可以测试核数更多机器上，OSP的压测性能，确定OSP程序的多核场景下特性。

虽然该项目客户的容器测试后，客户也反馈内部私有化改造中，我们的分析思路客户非常认可，通过测试分析，客户也对我们的容器服务和专业的态度留下良好印象。为后续打下良好基础。