资讯专栏INFORMATION COLUMN

容器隔离性带来的问题--容器化Java应用比虚机启动速度慢

王陆宽 / 1229人阅读

摘要:查看了容器和虚机所在主机的频率后,进一步证实了涛哥的猜想,频率确实有将近一倍的差异。在怀疑是隔离引起的问题后,对比了虚机和容器中进程的线程数,发现确实有比较大的差异。

引发的问题

同等配置下,虚机中的java 服务的启动速度,要比容器快很多(将近两倍)

实测数据

在同是1c1g的虚机和容器中,虚机启动时间大概在1min20s,容器启动时间大概在2min40s。

排查思路 怀疑网络

最开始怀疑是网络问题,因为业务依赖外部数据库,在容器和虚机中ping、telnet外部数据库,能通而且延迟差不多。

咨询熟悉java的小伙伴,说 spingboot可能有潜在的外部网络请求延迟(如请求Spring官网等),请求可能多次失败超时,不影响服务启动,但会影响启动时间。通过在虚机和容器中抓包,抓到了一个外部域名,但是虚机容器中都可以正常联通。包括修改域名服务器,都没有效果

硬件差异

排查问题陷入僵局后,咨询小伙伴的建议,涛哥提出是不是因为硬件差异导致的?这是个新的思路,之前只关注了软件层面的。

google了下,确实有人遇到了因为cpu频率的差异,导致虚机和容器中业务性能的差异。查看了容器和虚机所在主机的cpu频率后,进一步证实了涛哥的猜想,cpu频率确实有将近一倍的差异。根据文章中提供的解决办法,通过修改cpu的工作模式,从
powersave到performance,来提高cpu的工作频率。命令如下:

# 查看cpu频率
# lscpu    
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                48
On-line CPU(s) list:   0-47
Thread(s) per core:    2
Core(s) per socket:    12
Socket(s):             2
NUMA node(s):          2
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 79
Model name:            Intel(R) Xeon(R) CPU E5-2650 v4 @ 2.20GHz
Stepping:              1
CPU MHz:               2494.133
CPU max MHz:           2900.0000
CPU min MHz:           1200.0000
BogoMIPS:              4389.67
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
···
# 查看cpu工作模式
# cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
powersave
powersave
...

# 修改cpu工作模式
# cpupower -c all frequency-set -g performance
# 查看每个cpu的频率
# grep -i mhz /proc/cpuinfo
cpu MHz        : 1870.495
cpu MHz        : 2348.156
cpu MHz        : 2160.900
cpu MHz        : 1918.896
··· 

在修改完cpu工作模式后,cpu MHz确实有很大的提高,但是实测容器中业务启动时间并没有预期的和虚机中的速度一样,只有一点优化。看来cpu MHz不是决定的影响因素。

后来详细查了一下,cpu MHz是个不断浮动的素质,cpu性能要看CPU max MHz和工作模式。两台宿主机的cpu型号是一致的,改动cpu工作模式影响有限

容器对java的隔离缺陷

在之前容器化java业务的时候就遇到了OOMKilled,以及Runtime.getRuntime().availableProcessors()获取的cpu核数问题。当时通过引入了lxcfs,以及替换jvm libnumcpus.so文件,通过环境变量注入cpu核数来解决这个问题。

在怀疑是隔离引起的问题后,对比了虚机和容器中java进程的线程数,发现确实有比较大的差异。命令如下:

# 虚机中
···
[root@data-message-b69c847c7-sjlrx /]# cat /proc/136/status |grep Threads
Threads:    42
[root@data-message-b69c847c7-sjlrx /]# cat /proc/136/status |grep Threads
Threads:    42
[root@data-message-b69c847c7-sjlrx /]# cat /proc/136/status |grep Threads
Threads:    42
[root@data-message-b69c847c7-sjlrx /]# cat /proc/136/status |grep Threads
Threads:    42
[root@data-message-b69c847c7-sjlrx /]# cat /proc/136/status |grep Threads
Threads:    42
[root@data-message-b69c847c7-sjlrx /]# cat /proc/136/status |grep Threads
Threads:    42
···


# 容器中
···
[root@data-message-79bb65797d-ffsfb /]# cat /proc/42/status |grep Threads
Threads:    74
[root@data-message-79bb65797d-ffsfb /]# cat /proc/42/status |grep Threads
Threads:    74
[root@data-message-79bb65797d-ffsfb /]# cat /proc/42/status |grep Threads
Threads:    76
[root@data-message-79bb65797d-ffsfb /]# cat /proc/42/status |grep Threads
Threads:    76
[root@data-message-79bb65797d-ffsfb /]# cat /proc/42/status |grep Threads
Threads:    76
···
解决办法

使用包含了cpu-online /sys/devices/system/cpu/online的lxcfs(我们之前引入的lxcfs还未支持cpu-online)

在引入新版lxcfs cpu-online后,线程数下降明显,启动速度有明显的改善,达到和虚机同等水平。

LXCFS 3.1.2 has been released

Virtualize /sys/devices/system/cpu/online

LXCFS now also partially virtualizes sysfs. The first file to virtualize is /sys/devices/system/cpu/online per container.

结论

容器java进程启动慢的最终原因,还是容器的隔离性不够,导致jvm启动过多的线程,线程频繁切换带来的性能下降。目前使用包含cpu-online的lxcfs能解决这个问题。

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/75961.html

相关文章

  • 有赞容器实践

    摘要:有赞容器化方案我们的容器化方案基于和,下面介绍一下我们在各个方面遇到的问题以及解决方案。不过对于上线来说,需要整个运维体系来适配容器化,比如监控发布日志等等。 前言 容器化已经成为一种趋势,它可以解决很多运维中的痛点,比如效率、成本、稳定性等问题,而接入容器的过程中往往也会碰到很多问题和不便。在有赞最开始做容器化是为了快速交付开发测试环境,在容器化的过程中,我们碰到过容器技术、运维体系...

    songze 评论0 收藏0
  • 有赞容器实践

    摘要:有赞容器化方案我们的容器化方案基于和,下面介绍一下我们在各个方面遇到的问题以及解决方案。不过对于上线来说,需要整个运维体系来适配容器化,比如监控发布日志等等。 前言 容器化已经成为一种趋势,它可以解决很多运维中的痛点,比如效率、成本、稳定性等问题,而接入容器的过程中往往也会碰到很多问题和不便。在有赞最开始做容器化是为了快速交付开发测试环境,在容器化的过程中,我们碰到过容器技术、运维体系...

    EscapedDog 评论0 收藏0
  • 容器-Docker介绍

    摘要:容器作为一类操作系统层面的虚拟化技术,其目标是在单一主机交付多套隔离性环境,容器共享同一套主机操作系统内核。与其它容器平台不同,引入了一整套与容器管理相关的生态系统。每个容器都是相互隔离的保证安全的平台。 导读:本文章对Docker技术进行了介绍,阐述了Docker的技术发展历程、容器与虚拟机的差异、Docker原理、特点、Docker三组件和Docker带来的影响,为我们进一步理解D...

    李增田 评论0 收藏0
  • 容器还是虚拟机?企业云建设路线选择难题

    摘要:所以,无论是容器还是虚拟机,都可以实现弹性伸缩,其核心就是要注意状态和数据的分离和共享问题。通常来说,稳态的应用适合虚拟机,敏态的应用容器更胜一筹,但也不完全都是这样。笔者案前阵子与行业内的朋友聊到企业云的建设路线选择事宜,在涉及到虚拟化和容器技术的选择议题上讨论的比较多,基于当前容器技术在某些场景中有替代虚拟化的趋势,市场上也听到一些声称容器可能会完全取代虚拟化的声音。我个人也在思考,这两...

    JerryZou 评论0 收藏0
  • .Net大户选择:Windows Container在携程应用

    摘要:一些的技术细节最开始的时候携程用物理机部署应用,为了保证互不冲突,用户在一个物理机上只部署一个应用。目前支持的系统是,这个版本是去年月份正式发布的携程是国内比较早的一批拿到了他们的版本,支持两类,一类是,另一类是。 数人云上海&深圳两地容器之 Mesos/K8S/Swarm 三国演义的嘉宾精彩实录第四弹!小数已经被接连不断的干货搞晕了,沉浸技术的海洋好幸福~Windows contai...

    leo108 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<