問題描述 

        18個Strorage+1Tracker的線上環境,Stroage儲存18T磁碟剩餘空間平衡在97%左右.預設配置下頻繁出現圖片下載失敗的情況,由於客戶端程式碼使用了連線池,最終表現出連線資源不足.跟蹤若干Storage日誌偶爾有"send timeout"字樣的日誌.

猜測

線上環境對FastDFS Stroage，Tracker配置改動較少,依FastDFS架構檔案下載失敗不會是Tracker節點連線不足引起[Tracker是輕量級的節點],目前的連線數還不足以達到Tracker的瓶頸,重點調整客戶端配置和Stroage配置。

優化

Storage的配置引數有幾個猜測進行調整可能有用:

1. max_connections 預設為256,通過觀察所有節點的連線情況均為達到該臨界值都維持在20個連線左右,故而該引數暫不做改動,無須優化最大連線數.
   
   
2. accept_threads 該引數決定接收客戶端連線的執行緒數,預設值為1,適當放大該引數可改善Storage處理連線的能力,改成2[線上環境cpu為32核心可支援足夠多的執行緒數]
   
3. work_threads 工作執行緒用來處理網路IO,預設值為4,該引數影響Stroage可以同時處理的連線數,適當的調整這裡改為20.
4. disk_reader_threads 讀取磁碟資料的執行緒數,對應到每個儲存路徑,線上環境Storage只有一個路徑,預設為1,這裡改為5,提高讀取磁碟的執行緒數.
5. disk_writer_threads 寫磁碟的執行緒數量,也是對應一個儲存路徑,預設為1這裡修改為5

       對所有的Storage做如上修改後,依次重啟每一個節點,叢集穩定後,下載失敗的檔案數有減少,但依然有出現客戶端仍報連線超時,客戶端原有的超時時間為600毫秒，修改超時時間為1000毫秒,重啟所有客戶端。之後在未發現有圖片下載有異常. 每個Storage節點中的連線數任然維持在20個左右,但系統處理能力增強.

 總結

        分散式系統中,應充分利用多核CPU的處理能力,適當的調整執行緒數來優化處理能力,對IO型業務應該使用多執行緒來提高IO的續寫效率,避免排隊阻塞.

進一步優化

好景不長,第二天下午收到反饋，任然出現部分圖片下載失敗的情況,經排查這次下載失敗的原因為某個客戶端報" 無法獲取服務端連線資源：找不到可用的tracke"導致..  又出問題了我先去看看吧...  處理好了(還有幾個客戶端沒有調整),大概意思是Tracker不能在為客戶端提供更多的連線資源而拒絕服務,從而部分客戶端獲取不到Traker連線而報錯

        分析原因，第一部嘗試去調整Tracker處理連線相關的引數,tracker.conf中如下幾個引數可適當調整

        max_connections=1024  最大連線數,包括所有客戶端的讀寫連線數,可根據系統併發適當的調高,這裡修改為1024

        accept_threads=5    負責接收客戶端請求的執行緒數

        work_threads=25    負責處理客戶端請求的連線數,這裡只負責解析應該去哪個Stroage去下載/上傳圖片

        最後一步,調整客戶端連線池的大小,所有連線池資源的總和不應該超過上述配置的1024這個值,否則客戶端將報"找不到可用的tracke",修改連線池大小為30.  繼續觀察.

進一步優化

很遺憾，一個月左右的時間足以發生大的變故，期間進行過一次擴容操作，擴容操作後也都將對應的Storage節點進行了優化，通過fdfs_monitor工具檢視每個Storage上的連線數都維持在10個左右，和配置的最大值256差距很大。但客戶端還是頻繁出現圖片下載異常的情況，情況比之前更加糟糕.

        起初懷疑是否Tracker到達效能瓶頸，通過調整Tracker的執行緒數和連線數已經沒有什麼效果，檢視Tracker的連線數也維持在50條左右[nestat -anp |grep fdfs |wc -l],明顯Tracker並不是效能的關鍵,通過網路工具iptraf-ng測試到Tracker上的網路流量在1M/S左右，也沒有什麼問題。

      回頭在測試下每個Storage上的流量狀態 ，均值在40MB/S 遠遠未達到IO瓶頸,所有的Storage類似.   

     最終不得不懷疑是否客戶端實現的有問題,相比來說生產環境中使用的版本對客戶端進行了池化操作，請求使用Jetty容器通過Servlet進行暴露，首先通過調整Jetty的執行緒池大小、Http連線的佇列大小均沒有效果。最後直接拿掉資源池化的這一塊，直接使用原始API一對一的進行下載，問題解決了。

      總結如下，FastDFS的整個架構設計為多執行緒模型，tracker在圖片下載過程中只做輕量級的重定向操作[只是用來判斷group在哪個節點],圖片下載由客戶端直連Storage進行,FastDFS不建立長連線，使用池化操作並不能帶來明顯的效率提升，相反使用即用即連線的方式能獲得更好的效能,及時釋放連線,在併發量大的情況下,通過適當的提高Tracker的執行緒數，Storage執行緒數，Client數量，Client執行緒數來提升整體效能. 目前算 下載系統滿載的總下載流量在1.5G/S左右.