Go開發的應用程序通常部署在容器中。在容器中運行時，重要的一點是要設置CPU限制以確保容器不會耗光主機上的所有CPU。但Go運行時不知道容器上設置的CPU限制，因此有可能會把所有可用的CPU都用光，從而造成應用延遲很高。這個問題曾經困擾過我，在這篇文章中，我將解釋發生了什麼以及如何修復。
Go垃圾收集器是如何工作的
這是對Go垃圾收集器(GC)的概要介紹，想要更深入了解，建議閱讀Go文檔以及Will Kennedy的系列文章。
絕大多數情況下，Go運行時在執行程序的同時執行垃圾收集，這意味著GC會與程序同時運行。然而，在GC過程中有兩個點需要Go運行時暫停所有Goroutine，從而確保數據完整性。在GC標記階段(Mark Phase)之前，運行時將暫停所有Goroutine，用以啟用寫屏障(write barrier)，確保在此之後創建的任何對象都不會被GC，這個階段稱為掃描終止(Sweep Termination)。在標記階段完成後，還有一個STW(stop the world)階段，被稱為標記終止(Mark Termination)，並且也是刪除寫屏障的過程。整個流程通常需要幾十微秒。
我創建了一個簡單的web應用，分配了大量內存，並使用以下命令在一個限制為4個CPU核的容器中運行，源代碼在Github上。
docker run --cpus=4 -p 8080:8080 $(ko build -L main.go)值得註意的是，docker CPU限制是硬性限制。可以設置--CPU-shares，表示隻在主機CPU受限時強制執行。這意味著如果主機有空閑容量，容器可以使用超出分配的CPU核。但是如果主機資源受限，那麼應用程序也將受到限制。
可以使用runtime/trace包收集trace，然後用go tool trace對其進行分析。下面的trace顯示了在我的機器上捕獲的一個GC周期，可以看到在Proc 5中STW階段的掃描終止和標記終止。
這個GC周期隻花了不到2.5ms，但我們在STW階段花費了近10%的時間。這是相當長的一段時間，特別是對於延遲敏感應用來說。
Linux調度器
完全公平調度程序(Complete Fair Scheduler, CFS)是在Linux 2.6.23中引入的，在2023年10月份發佈的Linux 6.6之前一直是默認調度程序，很可能你正在使用CFS。
CFS是一個比例共享調度器，意味著進程權重與允許使用的CPU內核數量成正比。例如，如果允許一個進程使用4個CPU核，那麼它的權重將為4。如果一個進程被允許使用2個CPU核心，它的權重將為2。
CFS通過分配一小部分CPU時間來實現，一個4核系統每秒鐘有4秒的CPU時間可以分配。當我們為容器分配多個CPU內核時，實際上是要求Linux調度器給它n個CPU的時間。
在上面的docker run命令中，指定了4個CPU，意味著容器每秒將獲得4秒的CPU時間。
問題
當Go運行時啟動時，為每個CPU內核創建一個操作系統線程。這意味著如果有一個16核的機器，Go運行時將創建16個操作系統線程，不管任何CGroup CPU限制。然後Go運行時使用這些操作系統線程來調度程序。
問題是Go運行時不知道CGroup的CPU限制，而是在所有16個操作系統線程上調度goroutine，意味著Go運行時預計每秒能夠使用16秒的CPU時間。
由於Go運行時需要在等待Linux調度器調度的線程上停止gooutine，因此將面臨長時間的STW時間，因為一旦容器使用超過了CPU配額，線程就不會被調度。
解決方案
Go通過設置GOMAXPROCS環境變量限制運行時將創建的CPU線程數量。這一次，使用以下命令來啟動容器:
docker run --cpus=4 -e GOMAXPROCS=4 -p 8080:8080 $(ko build -L main.go)下面是從與上面相同的應用程序捕獲的trace，現在使用與CPU配額匹配的GOMAXPROCS環境變量。
在這個trace中，盡管負載完全相同，但垃圾收集時間要短得多。GC周期小於1ms，STW時間為26μs，約為無限制時的1/10。
GOMAXPROCS應該設置為容器允許使用的CPU核數，通常情況應該向下取整，如果分配的CPU內核少於1個，則向上取整。可以用GOMAXPROCS=max(1, floor(cpu))來計算。Uber開源了一個庫automaxprocs來自動從容器的cgroups中計算這個值。
有一個Github問題支持將這個特性添加到Go運行時中，使其開箱即用，希望最終會被Go運行時接受！
結論
在容器化應用程序中運行Go時，設置CPU限制非常重要。通過設置合理的GOMAXPROCS值或使用像automaxprocs這樣的庫，確保Go運行時意識到這些限制也很重要。