摘要：查看了容器和虛機(jī)所在主機(jī)的頻率后，進(jìn)一步證實了濤哥的猜想，頻率確實有將近一倍的差異。在懷疑是隔離引起的問題后，對比了虛機(jī)和容器中進(jìn)程的線程數(shù)，發(fā)現(xiàn)確實有比較大的差異。

同等配置下，虛機(jī)中的java 服務(wù)的啟動速度，要比容器快很多（將近兩倍）

在同是1c1g的虛機(jī)和容器中，虛機(jī)啟動時間大概在1min20s，容器啟動時間大概在2min40s。

最開始懷疑是網(wǎng)絡(luò)問題，因為業(yè)務(wù)依賴外部數(shù)據(jù)庫，在容器和虛機(jī)中ping、telnet外部數(shù)據(jù)庫，能通而且延遲差不多。

咨詢熟悉java的小伙伴，說 spingboot可能有潛在的外部網(wǎng)絡(luò)請求延遲（如請求Spring官網(wǎng)等），請求可能多次失敗超時，不影響服務(wù)啟動，但會影響啟動時間。通過在虛機(jī)和容器中抓包，抓到了一個外部域名，但是虛機(jī)容器中都可以正常聯(lián)通。包括修改域名服務(wù)器，都沒有效果

排查問題陷入僵局后，咨詢小伙伴的建議，濤哥提出是不是因為硬件差異導(dǎo)致的？這是個新的思路，之前只關(guān)注了軟件層面的。

google了下，確實有人遇到了因為cpu頻率的差異，導(dǎo)致虛機(jī)和容器中業(yè)務(wù)性能的差異。查看了容器和虛機(jī)所在主機(jī)的cpu頻率后，進(jìn)一步證實了濤哥的猜想，cpu頻率確實有將近一倍的差異。根據(jù)文章中提供的解決辦法，通過修改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確實有很大的提高，但是實測容器中業(yè)務(wù)啟動時間并沒有預(yù)期的和虛機(jī)中的速度一樣，只有一點優(yōu)化?？磥韈pu MHz不是決定的影響因素。

后來詳細(xì)查了一下，cpu MHz是個不斷浮動的素質(zhì)，cpu性能要看CPU max MHz和工作模式。兩臺宿主機(jī)的cpu型號是一致的，改動cpu工作模式影響有限

在之前容器化java業(yè)務(wù)的時候就遇到了OOMKilled，以及Runtime.getRuntime().availableProcessors()獲取的cpu核數(shù)問題。當(dāng)時通過引入了lxcfs，以及替換jvm libnumcpus.so文件，通過環(huán)境變量注入cpu核數(shù)來解決這個問題。

在懷疑是隔離引起的問題后，對比了虛機(jī)和容器中java進(jìn)程的線程數(shù)，發(fā)現(xiàn)確實有比較大的差異。命令如下：

# 虛機(jī)中
···
[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后，線程數(shù)下降明顯，啟動速度有明顯的改善，達(dá)到和虛機(jī)同等水平。

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進(jìn)程啟動慢的最終原因，還是容器的隔離性不夠，導(dǎo)致jvm啟動過多的線程，線程頻繁切換帶來的性能下降。目前使用包含cpu-online的lxcfs能解決這個問題。