雲服務器集羣性能故障排查手記

做者：田逸（wx formyz）

本人的忠告

當前依然有部分人（包括一些程序員）認爲，用了雲主機，網上搜搜，安裝文檔配置一下，哪裏還須要什麼專業的系統管理員（俗稱運維狗）。固然，這也有云服務商宣傳上的暗示（買了雲主機，穩定無憂，數據扔上去一勞永逸）。事實果然如此麼？若是你的應用沒什麼流量，一天沒幾我的訪問，還真不用花錢僱用專職系統管理員；若是你靠互聯網養活一幫人，並且但願有更多的用戶訪問，還有上述認知的話，我只能呵呵…

 

非系統管理員部署的環境

某個應用，所有在某公有云上。由負載均衡、四臺web應用、共享數據磁盤（程序代碼共享）、數據庫（主從）等及部分組成。從結構上看，嗯，沒什麼問題。所以，好長一段時間，也沒有人來找咱們作支持，咱們也不知道有這些應用存在。

 

秋天來了，帝都的天氣不錯嘛，想必你們心情跟天氣同樣，也是開心的嘛！但是最近，技術支持的qq羣，老有人在呼喚，說項目的四臺服務器所有負載飆高。晚上9點到11點load能到好幾百。說相關人員排查了好幾天，沒有效果（俺獨自偷笑一番）。

 

 

勘察現場

應用程序爲nginx + php + mysql，那麼可能的存在瓶頸與能夠調整的地方大體包括：系統配置、php配置、數據庫配置（雲服務商的負載均衡沒啥可調的）。閒話少說，催得那麼急，先看看運行情況吧。

My god，跑這麼高還沒死，贊一個先。除了cpu負載高而外，內存也基本耗盡。按照以往的經驗，有多是系統參數的設置問題（默認systcl.conf未進行設置），因而安排個人小弟從別的服務器參考一下，對其進行設置，執行sysctl –p使其生效。等訪問高峯期跟蹤觀察，結果效果不佳，看來得親自出馬了。

 

排查及處理過程

選定時間點，即訪問高峯期前一個小時，登陸系統。

 

先看看是什麼把內存給幹完了，ps 查看進程，發現大量的php進行。初步懷疑用戶請求完數據後，爲了有效關閉進程並釋放資源，在徵得贊成後，重啓php服務。片刻，進程又把內存耗光了，不太對勁呢！

 

重複執行下列命令對php進程進行統計：

ps auxww|grep php|grep –v grep |wc  -l

ps auxww|grep php|grep –v grep |wc  -l

進程數一直保持不變，數量爲601。一個進程佔用好幾兆內存，600個進程，最低下限耗費數G的內存，負載不高才怪了。

 

打開配置文件php-fpm.conf，一眼就看到問題所在

進程管理被錯誤的設置成static（靜態），最大子進程爲600，那麼一旦啓動php，無論有沒有必要，都會啓動一個主進程加600個子進程。配置文件php-fpm.conf 最大子進程這一行之後與動態管理相關的參數，如最大開始進程、最大空閒進程數等一概無效。修正這個問題後，時間差很少到了訪問高峯期。經過人工跟蹤加監控報警，基本上算是有很大改進，負載峯值load在50如下。

 

進一步的優化措施

雖然經過修正php參數設置，性能得以改善，但我對這個結果仍是不太滿意。想再看看有麼有能夠調整的地方。因而，思路到了磁盤io這個問題上了。

 

四個服務器共享一個雲nas硬盤，只保存一份程序員寫的php代碼。若是io性能不佳，也會嚴重影響整個應用的性能。

 

用mount指令查看nfs掛接狀況，主要是掛接參數，結果以下：

用的是tcp協議，而在之前的實踐中，我一般用udp協議（vers=3）進行掛接。考慮到雲服務商提供的磁盤性能，用tcp未必就能比udp更好。因而跟其餘人協商，在不影響性能訪問的狀況下，先修改一臺服務器對nfs的掛接方式，有進一步性能提高後再修改其餘的服務器，最後留一臺不作更改，以便觀察對比效果。

 

關服務，切換出掛接點目錄，卸載nfs，用下列指令掛接從新掛接nfs：

/usr/bin/mount -t nfs -o nolock,vers=3 6e46868719-pgn67.cn-qingdao.nas.aliyuncs.com:/   /data

/usr/bin/mount -t nfs -o nolock,vers=3 6e46868719-pgn67.cn-qingdao.nas.aliyuncs.com:/   /data

再啓動php等相關服務，高峯時期，效果很是明顯，load值下降到5如下。

 

通過數天的觀察，對比，雲服務器nfs掛接方式對性能的影響也比較大。