Docker上的cpushare設置令人困惑。

我在python寫了一個測試程序 'cputest.py' 是這樣的：Docker上的cpushare設置令人困惑。

import time 
while True: 
    for _ in range(10120*40): 
     pass 
    time.sleep(0.008)

，在一個容器中運行時（沒有其他runnng容器的干擾），該收費是80％ CPU。

然後我在兩個容器中跑出該程序由以下兩個命令：

docker run -d -c 256 --cpuset=1 IMAGENAME python /cputest.py 

docker run -d -c 1024 --cpuset=1 IMAGENAME python /cputest.py

和使用「頂部」，以查看它們的CPU成本。原來，他們相對成本30％和67％ cpu。這個結果讓我很困惑。有人會爲我解釋嗎？非常感謝！

來源

2014-10-09 Rui

沒有答案，但這可能有幫助：https://www.kernel.org/doc/Documentation/scheduler/sched-design-CFS.txt – Andy 2014-10-10 00:10:32

我昨晚坐了下來，試圖自己解決這個問題，但最終無法解釋70/30分裂。所以，我發了封郵件給一些其他的開發者，並得到了這種反應，我認爲是有道理的：

我想你是誤會稍微任務調度的工作方式 - 這就是爲什麼數學不起作用。我會嘗試挖掘一篇好文章，但是在基本級別上，內核會爲每個需要執行的任務分配片段時間，並將片段分配給具有給定優先級的任務。

因此，對於這些優先級和緊湊循環代碼（無睡眠），內核分配4/5的插槽給a和1/5到b。因此80/20分裂。

但是，當你加入睡眠時，它會變得更加複雜。睡眠基本上告訴內核產生當前任務，然後在睡眠時間結束後執行將返回到該任務。它可能比給定的時間更長 - 特別是如果有更高優先級的任務正在運行。當沒有別的東西在運行內核時，它只是在睡眠時間閒置。

但是，當你有兩個任務睡眠允許兩個任務交織。所以當一個人睡覺時，另一個人可以執行。這可能會導致一個複雜的執行，你不能用簡單的數學模型。隨時在這裏證明我錯了！

我認爲70/30分裂的另一個原因是你做「80％負荷」的方式。您爲環路和睡眠選擇的數字恰好在您的PC上正常工作，執行單個任務。您可以嘗試移動循環以基於經過的時間 - 循環爲0.8，然後爲0.2休眠。這可能會給你更接近80/20的東西，但我不知道。

因此，在本質上，你time.sleep()通話傾斜您的預計數字，去除time.sleep()導致CPU負載要遠遠更接近你所期望。

來源

2014-10-10 10:19:33

Docker上的cpushare設置令人困惑。

回答

相關問題