Go開發(fā)的應(yīng)用程序通常部署在容器中。在容器中運行時，重要的一點是要設(shè)置CPU限制以確保容器不會耗光主機(jī)上的所有CPU。但Go運行時不知道容器上設(shè)置的CPU限制，因此有可能會把所有可用的CPU都用光，從而造成應(yīng)用延遲很高。這個問題曾經(jīng)困擾過我，在這篇文章中，我將解釋發(fā)生了什么以及如何修復(fù)。

Go垃圾收集器是如何工作的

這是對Go垃圾收集器(GC)的概要介紹，想要更深入了解，建議閱讀Go文檔[2]以及Will Kennedy的系列文章[3]。

絕大多數(shù)情況下，Go運行時在執(zhí)行程序的同時執(zhí)行垃圾收集，這意味著GC會與程序同時運行。然而，在GC過程中有兩個點需要Go運行時暫停所有Goroutine，從而確保數(shù)據(jù)完整性。在GC標(biāo)記階段(Mark Phase)之前，運行時將暫停所有Goroutine，用以啟用寫屏障(write barrier)，確保在此之后創(chuàng)建的任何對象都不會被GC，這個階段稱為掃描終止(Sweep Termination)。在標(biāo)記階段完成后，還有一個STW(stop the world)階段，被稱為標(biāo)記終止(Mark Termination)，并且也是刪除寫屏障的過程。整個流程通常需要幾十微秒。

我創(chuàng)建了一個簡單的web應(yīng)用，分配了大量內(nèi)存，并使用以下命令在一個限制為4個CPU核的容器中運行，源代碼在Github[4]上。

docker run --cpus=4 -p 8080:8080 $(ko build -L main.go)

值得注意的是，docker CPU限制是硬性限制?？梢栽O(shè)置--CPU-shares，表示只在主機(jī)CPU受限時強制執(zhí)行。這意味著如果主機(jī)有空閑容量，容器可以使用超出分配的CPU核。但是如果主機(jī)資源受限，那么應(yīng)用程序也將受到限制。

可以使用runtime/trace[5]包收集trace，然后用go tool trace對其進(jìn)行分析。下面的trace顯示了在我的機(jī)器上捕獲的一個GC周期，可以看到在Proc 5中STW階段的掃描終止和標(biāo)記終止。

這個GC周期只花了不到2.5ms，但我們在STW階段花費了近10%的時間。這是相當(dāng)長的一段時間，特別是對于延遲敏感應(yīng)用來說。

Linux調(diào)度器

完全公平調(diào)度程序(Complete Fair Scheduler, CFS)[6]是在Linux 2.6.23中引入的，在2023年10月份發(fā)布的Linux 6.6之前一直是默認(rèn)調(diào)度程序，很可能你正在使用CFS。

CFS是一個比例共享調(diào)度器[7]，意味著進(jìn)程權(quán)重與允許使用的CPU內(nèi)核數(shù)量成正比。例如，如果允許一個進(jìn)程使用4個CPU核，那么它的權(quán)重將為4。如果一個進(jìn)程被允許使用2個CPU核心，它的權(quán)重將為2。

CFS通過分配一小部分CPU時間來實現(xiàn)，一個4核系統(tǒng)每秒鐘有4秒的CPU時間可以分配。當(dāng)我們?yōu)槿萜鞣峙涠鄠€CPU內(nèi)核時，實際上是要求Linux調(diào)度器給它n個CPU的時間。

在上面的docker run命令中，指定了4個CPU，意味著容器每秒將獲得4秒的CPU時間。

問題

當(dāng)Go運行時啟動時，為每個CPU內(nèi)核創(chuàng)建一個操作系統(tǒng)線程。這意味著如果有一個16核的機(jī)器，Go運行時將創(chuàng)建16個操作系統(tǒng)線程，不管任何CGroup CPU限制。然后Go運行時使用這些操作系統(tǒng)線程來調(diào)度程序。

問題是Go運行時不知道CGroup的CPU限制，而是在所有16個操作系統(tǒng)線程上調(diào)度goroutine，意味著Go運行時預(yù)計每秒能夠使用16秒的CPU時間。

由于Go運行時需要在等待Linux調(diào)度器調(diào)度的線程上停止gooutine，因此將面臨長時間的STW時間，因為一旦容器使用超過了CPU配額，線程就不會被調(diào)度。

解決方案

Go通過設(shè)置GOMAXPROCS環(huán)境變量限制運行時將創(chuàng)建的CPU線程數(shù)量。這一次，使用以下命令來啟動容器:

docker run --cpus=4 -e GOMAXPROCS=4 -p 8080:8080 $(ko build -L main.go)

下面是從與上面相同的應(yīng)用程序捕獲的trace，現(xiàn)在使用與CPU配額匹配的GOMAXPROCS環(huán)境變量。

在這個trace中，盡管負(fù)載完全相同，但垃圾收集時間要短得多。GC周期小于1ms，STW時間為26μs，約為無限制時的1/10。

GOMAXPROCS應(yīng)該設(shè)置為容器允許使用的CPU核數(shù)，通常情況應(yīng)該向下取整，如果分配的CPU內(nèi)核少于1個，則向上取整?？梢杂肎OMAXPROCS=max(1, floor(cpu))來計算。Uber開源了一個庫automaxprocs[8]來自動從容器的cgroups中計算這個值。

有一個Github問題[9]支持將這個特性添加到Go運行時中，使其開箱即用，希望最終會被Go運行時接受！

結(jié)論

在容器化應(yīng)用程序中運行Go時，設(shè)置CPU限制非常重要。通過設(shè)置合理的GOMAXPROCS值或使用像automaxprocs這樣的庫，確保Go運行時意識到這些限制也很重要。

參考資料

[1]Go, Containers, and the Linux Scheduler: https://www.riverphillips.dev/blog/go-cfs

[2]Go文檔: https://tip.golang.org/doc/gc-guide

[3]Garbage Collection In Go: https://www.ardanlabs.com/blog/2018/12/garbage-collection-in-go-part1-semantics.html

[4]示例代碼: https://github.com/RiverPhillips/go-cfs-blog

[5]runtime/trace package: https://golang.org/pkg/runtime/trace

[6]完全公平調(diào)度程序(Complete Fair Scheduler, CFS): https://docs.kernel.org/scheduler/sched-design-CFS.html

[7]Proportional share scheduling: https://en.wikipedia.org/wiki/Proportional_share_scheduling

[8]automaxprocs: https://github.com/uber-go/automaxprocs

[9]Github問題: https://github.com/golang/go/issues/33803