系統效能分析是困難的, 近日因為效能分析方向自己想做的事情, 加上對目前在各大討論網站提倡的主流方法有一些疑惑沒解開, 因此做了一些 Google 搜尋而找到此篇
當然現在主流是 perf / eBPF 這類 sampling-based 分析工具, 而這些也是各大討論區與網站主要提倡的工具, 然而真正地面對效能分析時, 很多時候必須弄清楚要發覺與處理的的問題本質為何?
這篇首先指出一個關鍵:
"Sampling profilers, the most common performance debugging tool, are notoriously bad at debugging problems caused by tail latency because they aggregate events into averages. But tail latency is, by definition, not average."
再者在許多問題的分析上, 從搜尋結果有相當高的可能會得到使用 sampling profiler 的結果, 然而因為對要處理的問題了解不足的結果, 直接套用建議後會發現: "But tools like OProfile are useless since they'll only tell us what's going on when our RPC is actively executing. What we really care about is what our thread is blocked on and why."
在文中舉了一個 Google 內實際發生的例子 - disk read latency 分析, 看似正常的分佈圖然而有著不合理的高延遲存在, (BTW 個人特別喜歡這段的一句 "each of you think of a guess, and you'll find you're all wrong"), 進而發現長時間廣泛存在於系統層面的問題. 而修正的獲益足以支付分析者十年以上的人事成本. 而這分析的例子主要在於提出 - "is this because of some flaw in existing profilers, or can profilers provide enough information that you don't need to use tracing tools to track down rare, long-tail, performance bugs?"
在討論 sampling limitation 之後, 文末段最後有3個問題, 其中最引人注目應該是:
3. Why are sampling profilers dominant?
除了說明認為未來 profiler 會愈來愈像 tracing tool 外, 也直接的回答了 - "but if we look at the state of things today, the easiest options are all classical profilers.", perf 提供運作的時間, 其他的基本工具提供消耗了多少記憶體, 結由這兩個數值能處理主要的效能問題.
此外也指出將現有公開工具湊在一起追蹤效能問題將會是個很困難的體驗, 文中提了一個實際的 case 做例證.
對於 tracing 的問題在於建立的困難度 - 對此通常有兩個選擇
1. 自己實作 - 基本上當然是 event + timestamp, 然而這當中還有該如何針對你的問題建立真的需要存下的 trace.(像是 lock & waiting) 來減少 overhead.
2. 從既有工具挑選你所需要的 - 然而不幸的是這些 overhead 成本都很高, 因此無法在特定規模以上在背景運作來復現出現的問題.
個人觀點:
1. sampling profiler 主要還是建立在 "比較" 的基準上找尋問題點, 通常是版本變換造成行為不同的系統問題. 以此能以成本較低的方式找出, 但若認為一個 workload 是 "正常" 基本上要找出優化的是不容易的, 這類問題像是 task dispatch 與 thread synchronization.
2. profiling budget 觀念的建立 - 為了能在實際發生問題的當下作用而非事後的分析(因為很多可能是實驗環境而無法 reproducible), 對於產生需要的資訊建立 overhead 要求. 在此之下建立能達成目的的 framework.
3. 統計數據的解讀能力 - 對整體與極端數值的解讀能力是分析問的的根本. 文中對於 disk latency 的 histogram 解釋能力即是一例.
4. sampling 是個好工具, 但必須了解其極限, 以及發現可能問題開如何找下一步
"Sampling profilers, the most common performance debugging tool, are notoriously bad at debugging problems caused by tail latency because they aggregate events into averages. But tail latency is, by definition, not average."
再者在許多問題的分析上, 從搜尋結果有相當高的可能會得到使用 sampling profiler 的結果, 然而因為對要處理的問題了解不足的結果, 直接套用建議後會發現: "But tools like OProfile are useless since they'll only tell us what's going on when our RPC is actively executing. What we really care about is what our thread is blocked on and why."
在文中舉了一個 Google 內實際發生的例子 - disk read latency 分析, 看似正常的分佈圖然而有著不合理的高延遲存在, (BTW 個人特別喜歡這段的一句 "each of you think of a guess, and you'll find you're all wrong"), 進而發現長時間廣泛存在於系統層面的問題. 而修正的獲益足以支付分析者十年以上的人事成本. 而這分析的例子主要在於提出 - "is this because of some flaw in existing profilers, or can profilers provide enough information that you don't need to use tracing tools to track down rare, long-tail, performance bugs?"
在討論 sampling limitation 之後, 文末段最後有3個問題, 其中最引人注目應該是:
3. Why are sampling profilers dominant?
除了說明認為未來 profiler 會愈來愈像 tracing tool 外, 也直接的回答了 - "but if we look at the state of things today, the easiest options are all classical profilers.", perf 提供運作的時間, 其他的基本工具提供消耗了多少記憶體, 結由這兩個數值能處理主要的效能問題.
此外也指出將現有公開工具湊在一起追蹤效能問題將會是個很困難的體驗, 文中提了一個實際的 case 做例證.
對於 tracing 的問題在於建立的困難度 - 對此通常有兩個選擇
1. 自己實作 - 基本上當然是 event + timestamp, 然而這當中還有該如何針對你的問題建立真的需要存下的 trace.(像是 lock & waiting) 來減少 overhead.
2. 從既有工具挑選你所需要的 - 然而不幸的是這些 overhead 成本都很高, 因此無法在特定規模以上在背景運作來復現出現的問題.
個人觀點:
1. sampling profiler 主要還是建立在 "比較" 的基準上找尋問題點, 通常是版本變換造成行為不同的系統問題. 以此能以成本較低的方式找出, 但若認為一個 workload 是 "正常" 基本上要找出優化的是不容易的, 這類問題像是 task dispatch 與 thread synchronization.
2. profiling budget 觀念的建立 - 為了能在實際發生問題的當下作用而非事後的分析(因為很多可能是實驗環境而無法 reproducible), 對於產生需要的資訊建立 overhead 要求. 在此之下建立能達成目的的 framework.
3. 統計數據的解讀能力 - 對整體與極端數值的解讀能力是分析問的的根本. 文中對於 disk latency 的 histogram 解釋能力即是一例.
4. sampling 是個好工具, 但必須了解其極限, 以及發現可能問題開如何找下一步
