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

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

动态测试模型和结果:

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

过程分析:

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

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

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程序的多核场景下特性。

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

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏编程

教你从零开始搭建一款前端脚手架工具

本文系原创,转载请注明:作者:Jrain Lau(https://segmentfault.com/u/jrainlau)项目地址:https://github...

4087
来自专栏何俊林

美团猫眼电影Android模块化实战总结

首先一句话概括:我想把这几个月做的事情记录下来,并且希望尽量详细,希望读者读了这篇文章能够知道项目进行模块化,项目改业务框架可能会遇到哪些问题,具体每个步骤都做...

2842
来自专栏技术小黑屋

快速提高Android开发效率的Web工具

在Google的广大支持下,便捷开发Android程序的Native工具层出不穷。其实Android开发涉及到的范围也不小,一些Web工具有时候也会带来事半功倍...

1452
来自专栏大数据智能实战

protobuf 转换python代码时发生 Expected "required", "optional", or "repeated".错误解决方法

        Google Protocol Buffers 简称 Protobuf,它提供了一种灵活、高效、自动序列化结构数据的机制,可以联想 XML,但是...

2408
来自专栏杨建荣的学习笔记

Python多线程并发的简单测试

之前也写了一些简单的Python程序,对于多线程的并发一直没有涉及,今天决定先突破一下,把这个部分的内容先快速的掌握,然后在这个基础上细化改进。 我的...

38311
来自专栏架构师之路

90行代码,搞定日志监控框架

上一篇《100行代码,搞定http监控框架》介绍了通用+可扩展的http监控平台的架构: 监控平台层:调度监控项,通过后台管理监控项 信息管理层:通过服务和后台...

8207
来自专栏MongoDB中文社区

完美数据迁移-MongoDB Stream的应用

尽管如此,目前还是有许多企业踏上了服务化改造的道路,这其中则免不了”旧改”的各种繁杂事。

1092
来自专栏移动端周边技术扩展

移动端Weex平台开发文档

2126
来自专栏北京马哥教育

Linux 软中断机制分析

软中断分析最近工作繁忙,没有时间总结内核相关的一些东西。上次更新博客到了linux内核中断子系统。这次总结一下软中断,也就是softirq。之后还会总结一些ta...

4638
来自专栏我是攻城师

多线程基础知识了解一下

作为一名优秀的攻城师,了解多线程的知识非常有必要,尤其在人工智能和机器学习的热潮下,如何提高程序或者算法的运行效率是非常有价值的一件事情。

1394

扫码关注云+社区