引發的問題

同等配置下，虛機中的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能解決這個問題。

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的java 提高性能的 容器库_容器隔离性带来的问题--容器化Java应用比虚机启动速度慢...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。