内容简介：线上用的k8s版本是1.6.7非常老，而且HA有问题，上个月研发想把里面的一些服务迁出来到一个新集群里，新集群的搭建是我负责的。上周开始陆陆续续的迁移过来了，但是同等limit下部分pod在测试环境上(测试环境和老环境部署是一样的,下文的老环境和测试环境可以理解为一样)启动非常快，在我搭建的新k8s环境上启动非常慢，研发他们应用都是java+springboot，这里不谈jvm无法识别cgroup，已经加选项识别到了还有那个随机熵的选项肯定也是加了的。因为之前一次有个用户反映他们本地虚机启动springbo
线上用的k8s版本是1.6.7非常老，而且HA有问题，上个月研发想把里面的一些服务迁出来到一个新集群里，新集群的搭建是我负责的。上周开始陆陆续续的迁移过来了，但是同等limit下部分pod在测试环境上(测试环境和老环境部署是一样的,下文的老环境和测试环境可以理解为一样)启动非常快，在我搭建的新k8s环境上启动非常慢，研发他们应用都是java+springboot，这里不谈jvm无法识别cgroup，已经加选项识别到了还有那个随机熵的选项肯定也是加了的。
因为之前一次有个用户反映他们本地虚机启动springboot应用20s，我们云上启动就三分钟，后面漠然大佬教我加 java 的启动参数输出log，帮我远程debug找到原因是zk客户端会解析hosts，加条localhost的hosts就解决了。在得知他们用的也是springboot后一开始就怀疑是他们代码问题(毕竟java)，建议他们去开debug自己看log。
四五天之前研发那边和我对接k8s的同事详细的探讨了启动不一致的问题，我询问了哪个pod可以随意启停，然后在新环境上把该pod的command改成sh和 tty:true
，去掉就绪和生存探针手动进去启动进程，启动的时候加了java的运行参数打印一系列的更详细的log，把log发给qingmu.io大佬，大佬看了说了句你这cpu限制得太厉害了吧。我才发现新环境上pod的cpu限制得比老环境还小，然后改成老环境一样就非常快了。
然后今天研发同事又说启动慢，限制一样的还是启动慢，这里放下他说的原话: 相同资源下，A环境服务比测试环境启动慢上一倍-3倍,当cpu3核时，启动时间差距就没那么大了
，这个话和qingmu.io大佬之前看到日志说cpu限制得太厉害了是提示了我找到原因的关键。
然后同事截图了下pod的limit，我看到cpu是1，这不刚好3倍吗，毕竟k8s的容器cpu限制是基于时间占比的，寻思着cpu是不是不一样，叫同事把他们那边测试环境的lscpu输出截图
$ lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 24 On-line CPU(s) list: 0-23 Thread(s) per core: 1 Core(s) per socket: 1 Socket(s): 24 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 15 Model: 6 Model name: Intel(R) Xeon(R) Gold 5118 CPU @ 2.30GHz Stepping: 3 CPU MHz: 2700.017 BogoMIPS: 4589.20 Hypervisor vendor: KVM Virtualization type: full L1d cache: 32K L1i cache: 32K L2 cache: 4096K L3 cache: 16384K NUMA node0 CPU(s): 0-23 Flags: fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx lm constant_tsc nopl xtopology eagerfpu pni cx16 x2apic hypervisor lahf_lm
下面这个是新环境的lscpu输出
Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 56 On-line CPU(s) list: 0-55 Thread(s) per core: 2 Core(s) per socket: 14 Socket(s): 2 NUMA node(s): 2 Vendor ID: GenuineIntel CPU family: 6 Model: 85 Model name: Intel(R) Xeon(R) Gold 6132 CPU @ 2.60GHz Stepping: 4 CPU MHz: 999.914 CPU max MHz: 3700.0000 CPU min MHz: 1000.0000 BogoMIPS: 5200.00 Virtualization: VT-x L1d cache: 32K L1i cache: 32K L2 cache: 1024K L3 cache: 19712K NUMA node0 CPU(s): 0-13,28-41 NUMA node1 CPU(s): 14-27,42-55
这一对比就发现了问题所在，新环境的cpu频率平均稳定在999.914,也就是 CPU MHz
，测试环境是虚机，虽说它没max和min Mhz(应该是虚拟化相关的设置导致没有的)但是它的平均频率也约等于新环境平均频率的三倍，寻思着应该是cpu的省电模式之类的，一对比发现每个核心频率都很低
$ grep -i mhz /proc/cpuinfo cpu MHz : 999.914 cpu MHz : 999.914 cpu MHz : 999.914 cpu MHz : 1000.073 cpu MHz : 999.914 cpu MHz : 999.914 cpu MHz : 999.914 cpu MHz : 999.914 cpu MHz : 999.914 cpu MHz : 999.914 cpu MHz : 1000.073 cpu MHz : 999.914 cpu MHz : 999.914 cpu MHz : 1000.073 cpu MHz : 1000.073 cpu MHz : 1000.073 cpu MHz : 999.914 cpu MHz : 999.914 cpu MHz : 999.914 cpu MHz : 999.914 cpu MHz : 999.914 cpu MHz : 999.914 cpu MHz : 999.914 cpu MHz : 999.914 cpu MHz : 999.914 cpu MHz : 1000.073 cpu MHz : 999.914 cpu MHz : 999.914 cpu MHz : 999.914 cpu MHz : 1000.231 cpu MHz : 1298.889 cpu MHz : 1001.025 cpu MHz : 1000.073 cpu MHz : 1000.390 cpu MHz : 1000.390 cpu MHz : 1000.231 cpu MHz : 1000.073 cpu MHz : 1000.708 cpu MHz : 1001.025 cpu MHz : 1000.231 cpu MHz : 999.914 cpu MHz : 1000.231 cpu MHz : 1000.073 cpu MHz : 1000.073 cpu MHz : 1382.519 cpu MHz : 1327.929 cpu MHz : 999.914 cpu MHz : 1157.653 cpu MHz : 1121.313 cpu MHz : 1000.073 cpu MHz : 1193.518 cpu MHz : 1000.073 cpu MHz : 1000.231 cpu MHz : 1000.390 cpu MHz : 1000.390 cpu MHz : 1000.073
然后查找了下设置cpu什么最小频率的命令给找到了下面信息.
在 Linux 中，内核的开发者定义了一套框架模型来完成CPU频率动态调整这一目的，它就是CPU Freq系统。尽管在各个Linux发行版中，前端软件稍有差异，但其最终都会通过Linux内核的CPU Freq系统来实现CPU频率动态调整的功能。这些软件都会提供如下CPU模式（governor参数）
使用下列命令查看cpu的模式（governor参数）
$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor powersave powersave ....
-
ondemand：系统默认的超频模式，按需调节，内核提供的功能，不是很强大，但有效实现了动态频率调节，平时以低速方式运行，当系统负载提高时候自动提高频率。以这种模式运行不会因为降频造成性能降低，同时也能节约电能和降低温度。一般官方内核默认的方式都是ondemand。
-
interactive：交互模式，直接上最高频率，然后看CPU负荷慢慢降低，比较耗电。Interactive 是以 CPU 排程数量而调整频率，从而实现省电。InteractiveX 是以 CPU 负载来调整 CPU 频率，不会过度把频率调低。所以比 Interactive 反应好些，但是省电的效果一般。
-
conservative：保守模式，类似于ondemand，但调整相对较缓，想省电就用他吧。Google官方内核，kang内核默认模式。
-
smartass：聪明模式，是I和C模式的升级，该模式在比interactive 模式不差的响应的前提下会做到了更加省电。
-
performance：性能模式！只有最高频率，从来不考虑消耗的电量，性能没得说，但是耗电量。
-
powersave 省电模式，通常以最低频率运行。
-
userspace：用户自定义模式，系统将变频策略的决策权交给了用户态应用程序，并提供了相应的接口供用户态应用程序调节CPU 运行频率使用。也就是长期以来都在用的那个模式。可以通过手动编辑配置文件进行配置
-
Hotplug：类似于ondemand, 但是cpu会在关屏下尝试关掉一个cpu，并且带有deep sleep，比较省电。
而新环境的cpu就是省电模式运行的，cpu频率极低，新环境不能重启，可能bios里有设置cpu工作模式选项，所以只能找在线修改的方法。查找了下设置模式的命令，最终找到了个靠谱的
$ cpupower -c all frequency-set -g performance Setting cpu: 0 Setting cpu: 1 Setting cpu: 2 ... Setting cpu: 55 $ /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor performance performance performance ...
模式已经改变了，查看下工核心的作频率
grep -i mhz /proc/cpuinfo cpu MHz : 1870.495 cpu MHz : 3127.331 cpu MHz : 2348.156 cpu MHz : 2160.900 cpu MHz : 1918.896 cpu MHz : 1756.237 cpu MHz : 2635.388 cpu MHz : 2115.673 cpu MHz : 1989.196 cpu MHz : 1708.312 cpu MHz : 2226.916 cpu MHz : 2683.471 cpu MHz : 1654.199 cpu MHz : 2696.643 cpu MHz : 2258.020 cpu MHz : 1957.299 cpu MHz : 2357.360 cpu MHz : 3345.214 cpu MHz : 3096.704 cpu MHz : 1361.413 cpu MHz : 2991.650 cpu MHz : 2209.777 cpu MHz : 2505.102 cpu MHz : 2493.359 cpu MHz : 1823.999 cpu MHz : 2132.812 cpu MHz : 2622.058 cpu MHz : 2049.340 cpu MHz : 2217.871 cpu MHz : 3294.592 cpu MHz : 2478.442 cpu MHz : 3284.436 cpu MHz : 3279.199 cpu MHz : 2265.002 cpu MHz : 2650.622 cpu MHz : 2250.720 cpu MHz : 1804.797 cpu MHz : 1626.269 cpu MHz : 2827.404 cpu MHz : 1602.783 cpu MHz : 3270.312 cpu MHz : 3283.166 cpu MHz : 1676.257 cpu MHz : 3270.312 cpu MHz : 3331.726 cpu MHz : 2591.748 cpu MHz : 3323.950 cpu MHz : 3312.683 cpu MHz : 2978.002 cpu MHz : 3251.269 cpu MHz : 2968.005 cpu MHz : 2234.216 cpu MHz : 1717.199 cpu MHz : 1733.227 cpu MHz : 2282.458 cpu MHz : 1455.358
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
架构即未来：现代企业可扩展的Web架构、流程和组织(原书第2版)
Martin L. Abbott、Michael T. Fisher / 陈斌 / 机械工业出版社 / 2016-4-15 / 99.00
任何一个持续成长的公司最终都需要解决系统、组织和流程的扩展性问题。本书汇聚了作者从eBay、VISA、Salesforce.com到Apple超过30年的丰富经验， 全面阐释了经过验证的信息技术扩展方法，对所需要掌握的产品和服务的平滑扩展做了详尽的论述，并在第1版的基础上更新了扩展的策略、技术和案例。 针对技术和非技术的决策者，马丁•阿伯特和迈克尔•费舍尔详尽地介绍了影响扩展性的各个方面，包......一起来看看 《架构即未来：现代企业可扩展的Web架构、流程和组织(原书第2版)》 这本书的介绍吧!
