關於find_busiest_group函數提現出的Linux性能問題

    最近在查一個pgoneproxy的性能問題，發現當pgoneproxy與postgresql數據庫部署到一臺主機上面的時候，經過perf top能夠看到find_busiest_group函數佔有很大的比例，而當pgoneproxy和postgresql部署到不一樣的機器上面的時候此函數則不出現。初步分析應該是某些資源不足致使的。

    爲了弄清楚這個問題，首先的搞清楚find_busiest_group這個函數的做用，根據參考文獻1）和2）瞭解到這個函數是與多核cpu的負載均衡有關係，及當有大量任務的時候分佈不均的話那麼此函數會被調用。那麼經過查看cpu的負載均衡狀況，發現具備以下的信息：

    其中load average的平均15分鐘的負載狀況是37.58.因爲個人主機是16邏輯CPU的，平均一個是2.34。這個cpu的隊列長隊比較長了。按照網絡上各位的說法有0.7的，也有2的。如今是2.34確定是超負載了。故當某個cpu的負載稍輕鬆點，那麼cpu將會經過find_busiest_group查找最繁忙的cpu隊列，把一部分進程移到輕鬆的cpu隊列中。

    這種狀況下，最好是把pgoneproxy與postgresql數據庫部署到不一樣的主機上面來解決cpu負載的問題。

    在經過atop工具，能夠查看到在進行大量的寫操做，見下圖的黑體部分：

查看上圖中的進程信息，能夠看到postgres在進行大量的寫磁盤操做。從而致使整個cpu的利用率不高（經過top觀察）。

參考文獻：

1）linux在多核處理器上的負載均衡原理

2）多處理器運行隊列的平衡

3）Linux Scheduling Domains

4）你值得擁有：25個Linux性能監控工具