大型企业网站建设制作,莱芜网络公司网站,如何开发一个app,制作ppt的步骤引发的问题同等配置下#xff0c;虚机中的java 服务的启动速度#xff0c;要比容器快很多(将近两倍)实测数据在同是1c1g的虚机和容器中#xff0c;虚机启动时间大概在1min20s#xff0c;容器启动时间大概在2min40s。排查思路怀疑网络最开始怀疑是网络问题#xff0c;因为业…引发的问题同等配置下虚机中的java 服务的启动速度要比容器快很多(将近两倍)实测数据在同是1c1g的虚机和容器中虚机启动时间大概在1min20s容器启动时间大概在2min40s。排查思路怀疑网络最开始怀疑是网络问题因为业务依赖外部数据库在容器和虚机中ping、telnet外部数据库能通而且延迟差不多。咨询熟悉java的小伙伴说 spingboot可能有潜在的外部网络请求延迟(如请求Spring官网等)请求可能多次失败超时不影响服务启动但会影响启动时间。通过在虚机和容器中抓包抓到了一个外部域名但是虚机容器中都可以正常联通。包括修改域名服务器都没有效果硬件差异排查问题陷入僵局后咨询小伙伴的建议涛哥提出是不是因为硬件差异导致的这是个新的思路之前只关注了软件层面的。google了下确实有人遇到了因为cpu频率的差异导致虚机和容器中业务性能的差异。查看了容器和虚机所在主机的cpu频率后进一步证实了涛哥的猜想cpu频率确实有将近一倍的差异。根据文章中提供的解决办法通过修改cpu的工作模式从powersave到performance来提高cpu的工作频率。命令如下# 查看cpu频率# lscpuArchitecture: x86_64CPU op-mode(s): 32-bit, 64-bitByte Order: Little EndianCPU(s): 48On-line CPU(s) list: 0-47Thread(s) per core: 2Core(s) per socket: 12Socket(s): 2NUMA node(s): 2Vendor ID: GenuineIntelCPU family: 6Model: 79Model name: Intel(R) Xeon(R) CPU E5-2650 v4 2.20GHzStepping: 1CPU MHz: 2494.133CPU max MHz: 2900.0000CPU min MHz: 1200.0000BogoMIPS: 4389.67Virtualization: VT-xL1d cache: 32KL1i cache: 32KL2 cache: 256K···# 查看cpu工作模式# cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governorpowersavepowersave...# 修改cpu工作模式# cpupower -c all frequency-set -g performance# 查看每个cpu的频率# grep -i mhz /proc/cpuinfocpu MHz : 1870.495cpu MHz : 2348.156cpu MHz : 2160.900cpu 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进程的线程数发现确实有比较大的差异。命令如下# 虚机中···[rootdata-message-b69c847c7-sjlrx /]# cat /proc/136/status |grep ThreadsThreads: 42[rootdata-message-b69c847c7-sjlrx /]# cat /proc/136/status |grep ThreadsThreads: 42[rootdata-message-b69c847c7-sjlrx /]# cat /proc/136/status |grep ThreadsThreads: 42[rootdata-message-b69c847c7-sjlrx /]# cat /proc/136/status |grep ThreadsThreads: 42[rootdata-message-b69c847c7-sjlrx /]# cat /proc/136/status |grep ThreadsThreads: 42[rootdata-message-b69c847c7-sjlrx /]# cat /proc/136/status |grep ThreadsThreads: 42···# 容器中···[rootdata-message-79bb65797d-ffsfb /]# cat /proc/42/status |grep ThreadsThreads: 74[rootdata-message-79bb65797d-ffsfb /]# cat /proc/42/status |grep ThreadsThreads: 74[rootdata-message-79bb65797d-ffsfb /]# cat /proc/42/status |grep ThreadsThreads: 76[rootdata-message-79bb65797d-ffsfb /]# cat /proc/42/status |grep ThreadsThreads: 76[rootdata-message-79bb65797d-ffsfb /]# cat /proc/42/status |grep ThreadsThreads: 76···解决办法使用包含了cpu-online /sys/devices/system/cpu/online的lxcfs(我们之前引入的lxcfs还未支持cpu-online)在引入新版lxcfs cpu-online后线程数下降明显启动速度有明显的改善达到和虚机同等水平。LXCFS 3.1.2 has been releasedVirtualize /sys/devices/system/cpu/onlineLXCFS now also partially virtualizes sysfs. The first file to virtualize is /sys/devices/system/cpu/online per container.结论容器java进程启动慢的最终原因还是容器的隔离性不够导致jvm启动过多的线程线程频繁切换带来的性能下降。目前使用包含cpu-online的lxcfs能解决这个问题。
