資訊專欄INFORMATION COLUMN
摘要：查看了容器和虛機所在主機的頻率后，進一步證實了濤哥的猜想，頻率確實有將近一倍的差異。在懷疑是隔離引起的問題后，對比了虛機和容器中進程的線程數，發現確實有比較大的差異。
引發的問題
同等配置下，虛機中的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 releasedVirtualize /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能解決這個問題。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/75961.html
摘要：有贊容器化方案我們的容器化方案基于和，下面介紹一下我們在各個方面遇到的問題以及解決方案。不過對于上線來說，需要整個運維體系來適配容器化，比如監控發布日志等等。 前言 容器化已經成為一種趨勢，它可以解決很多運維中的痛點，比如效率、成本、穩定性等問題，而接入容器的過程中往往也會碰到很多問題和不便。在有贊最開始做容器化是為了快速交付開發測試環境，在容器化的過程中，我們碰到過容器技術、運維體系...
摘要：容器作為一類操作系統層面的虛擬化技術，其目標是在單一主機交付多套隔離性環境，容器共享同一套主機操作系統內核。與其它容器平臺不同，引入了一整套與容器管理相關的生態系統。每個容器都是相互隔離的保證安全的平臺。 導讀：本文章對Docker技術進行了介紹，闡述了Docker的技術發展歷程、容器與虛擬機的差異、Docker原理、特點、Docker三組件和Docker帶來的影響，為我們進一步理解D...
摘要：所以，無論是容器還是虛擬機，都可以實現彈性伸縮，其核心就是要注意狀態和數據的分離和共享問題。通常來說，穩態的應用適合虛擬機，敏態的應用容器更勝一籌，但也不完全都是這樣。筆者案前陣子與行業內的朋友聊到企業云的建設路線選擇事宜，在涉及到虛擬化和容器技術的選擇議題上討論的比較多，基于當前容器技術在某些場景中有替代虛擬化的趨勢，市場上也聽到一些聲稱容器可能會完全取代虛擬化的聲音。我個人也在思考，這兩...
閱讀 647·2021-10-27 14:15
閱讀 1175·2021-10-15 09:42
閱讀 2744·2019-08-30 15:53
閱讀 1285·2019-08-23 17:02
閱讀 2962·2019-08-23 16:23
閱讀 3181·2019-08-23 15:57
閱讀 3463·2019-08-23 14:39
閱讀 516·2019-08-23 14:35
