GC 對 throughput 與延遲時間的影響

原文網址：https://plumbr.eu/blog/gc-impact-on-throughput-and-latency

---

有一類問題是每一個 Java application 都會遇到的，那就是 GC。當 GC 正常運作時，它是一個美妙的發明；當它沒有運作、或是 GC 用出乎意料的方式運作，那你的朋友就會翻臉變成仇人。

這篇文章是關於 GC 造成的暫停時間。或著更精確地說：為什麼你要在意這些暫停時間？

前幾篇文章，我用 Apple CEO Tim Cook 針對 iPad 需求與建廠的規劃，來解釋 throughput 與延遲時間。這裡我將沿用同一個例子：

• 我們有一個生產線每秒可以製造一台 iPad。所以這條生產線的 throughput 是每天 86400 台 iPad。
• 從外殼成型開始到驗收測試結束，一台 iPad 需要 4 小時的時間。所以這條生產線的延遲時間是 4 個小時。

上述系統以及計算結果，是假設生產線每天不間斷地運作 24 小時。但是所有生產線都需要保養，對應到 JVM 就是執行 GC。

舉例來說，作小型保養可以在不怎麼中斷製程的情況下處理完畢；可能是幫機器上油、或是把塑模設備旁邊地板的垃圾撿起來。這些操作行為跟 JVM 中的 minor GC 相似，你必須作這些維護。不過，因為實作寫得太聰明，所以對系統效能來說沒什麼影響。

跟 Tim Cook 一樣，還是得面對長時間的維護任務。這些任務得停止整個生產線，相當於執行 full GC 時 JVM 需要暫停 thread 以作一些整理的工作。

現在假設在幾個月不間斷的服務之後，我們想像中的生產線卡住了，技術團隊需要 4 個小時才能解決問題，這段時間生產線是停止的。我們要如何計算影響程度？一如往常，影響程度可以從兩個不同面相去評估：

• throughput 的影響：停機的這 4 個小時代表有 14400 秒沒辦法做出 iPad。以 throughput 來看，在這特定的一天當中，系統的產能會從 86400 降到 72000。這代表 throughput 損失了約 16.5%。
• 延遲時間的影響：如果一台 iPad 在中斷作業的時候仍然在生產線上，則它的完成時間會長達 8 個小時而不是 4 個小時。這表示在最壞的情況下延遲時間增加了 100%。

如果你還記得，其實 Cook 並不在意延遲時間。對他而言，重點在於長時間區段內的整體 throughput。所以 Cook 決定以盡可能不影響 throughput 的方式來調整生產流程。

軟體開發也需要做出類似的決定。如果你有負責處理訂單的 Java EE application，那麼 GC 暫停超過 4 秒，肯定會降低系統的 throughput。但對大多數的人而言，這不是主要議題。另一方面，試圖在清理空間的這四秒鐘內作某些事情的使用者，會覺得我們的系統很遲鈍。讓使用者覺得服務操作起來很遲鈍，這是商業軟體的大忌。

這個故事告訴我們什麼？明智地選擇你的目標，並且確定你有搞清楚 throughput 跟延遲時間的區別。然後確保你瞭解 GC 的影響，無論是監看 GC 的 log 或是找尋意料外的 full GC 動作，並且調整 application 以及 GC 來將影響降到最低。

如果你看到這邊，那我還有一個有趣的故事。請看我們的舊文章，並考慮關注我們的 Twitter。