Postgresql CPU相關性能問題分析

在項目中，極可能會遇到CPU使用率過多。在跑測試過程當中，不少人若是發現了CPU不夠用怎麼辦？現分享出本身的性能分析思路。

      首先仍是多嘮叨幾句CPU相關的話題吧。CPU自己是熟悉計算機系統的硬件之一，從字面意思上應該也能想到其重要程度。能夠簡單地把CPU幹活理解爲「處理數據」，那麼數據從哪裏來？仍是簡單起見（這裏不是很嚴謹，可是爲了理解上的方便），能夠理解爲從磁盤和內存。好比更改「數據庫某行上的某個字段上值，首先把磁盤上存儲內容讀到內存中，處理完以後，更新過的數據存放在內存中，最後再寫回到磁盤中。這其中涉及到CPU,內存，磁盤。其實從全局的角度看，還包含操做系統（文件系統，磁盤IO等），網絡IO等。

      因此，1> 從以上你能夠發現和CPU問題相關的介質或組件其實有不少，可是遇到CPU的問題，咱們仍是優先想到，內存是否是也不夠了。這種想法是對的。由於從上一段落的分析能夠看到：數據存放到內存和數據存放到磁盤，對效率的影響是蠻大的。即便你用的是SSD,這種速度上的差異也是差多少個數量級。因此有多是內存也已經用完了，致使SQL執行效率不高。能夠考慮增大內存分配，再進行測試驗證。
      2> CPU在等待磁盤IO，或者磁盤IO比較忙，怎麼去判斷磁盤IO是否是繁忙呢？能夠經過以下命令，直接獲取，看最磁盤適用率，若是接近100%，證實是比較繁忙，能夠進一步深刻問題，能不能使用數據庫cache，或者將這部分邏輯的後臺遷移到memory store類型的存儲介質中，如redis等。避免此部分的業務邏輯形成瓶頸。

iostat -d -x -k 1

3> 線程資源爭搶，須要分析線程相關log。若是發現現場死鎖，無論是鎖在對象資源仍是數據庫資源，都須要優先修復。若是出現共享資源爭搶，那麼這部分邏輯的後臺，最好不要放在關係型數據庫中。

你們也能夠掃描並關注以下公衆號「TimTest」，會有更多性能測試相關內容分享。