線上模組XX 在高QPS下耗時劇增的原因排查總結

1、確定問題原因：

1）場景復現：方式1：根據現場日誌確定問題原因；方式2：壓測復現。

存在的問題：方式1：日誌中沒有儲存現場；方式2：壓測可能與線上不符；壓測可能無法滿足某些特殊條件。

2）一些手段：

a.如果問題只在特定機器出現，確定機器硬體配置是否相同，cpu、meminfo、系統配置等；

b.分階段、逐步細化各步驟的處理時間、佇列積壓長度等；

c.可以使用一些輔助效能分析工具進行分析，代價是學習成本，場景不一定符合效能分析工具作用的發揮。

最終發現的高qps時，耗時主要集中在資訊流配圖階段和it_proc特徵收集階段。

2、分析現象本質：

1）it_proc:

內部迴圈過多：按照it內部的引數預設值計算，最大迴圈次數達到百萬級別，在其他特徵收集基本0ms的情況下，it的耗時是不可接受的。

2）資訊流配圖：

分階段、逐步細化各步驟的處理時間並不能發現問題原因，這種情況就不能懷疑單次執行內部函式的耗時上，很有可能是系統在做切換、同步等處理時導致的異常。

對這一部分程式重新研讀，發現呼叫的std標準函式random_shuffle有重大嫌疑，在此懷疑的基礎上，注釋掉相關**，確實不再發生同樣的問題，問題得到確認。

is-random-shuffle-threadsafe-and-using-rand-r-if-it-is-not

3、問題修復方式：

1）it_proc:

和策略同學討論修復方式，誰開發誰維護的原則，發現是按權重抽樣演算法過於複雜，最後確定已現有ot的處理方式進行修改；

2）資訊流配圖：

a. 資訊流配圖也存在大量迴圈，首先將不需要再迴圈內部執行的**移到迴圈體外部，其次盡量在不影響功能的情況下降低迴圈次數。

b.對於random_shuffle的問題，採用基於rand_r自定義隨機生成器的方式呼叫

template void random_shuffle (randomaccessiterator first, randomaccessiterator last,randomnumbergenerator&& gen);

實現陣列打散。

4、總結：

1 確定問題原因 1 場景復現方式1 根據現場日誌確定問題原因方式2 壓測復現。存在的問題方式1 日誌中沒有儲存現場方式2 壓測可能與線上不符壓測可能無法滿足某些特殊條件。2 一些手段 a.如果問題只在特定機器出現，確定機器硬體配置是否相同，cpu meminfo 系統配置等 b.分階段 ...