云服務器集群性能故障排查手記

作者：田逸（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

進程數一直保持不變，數量為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

再啟動php等相關服務，高峰時期，效果非常明顯，load值降低到5以下。

?

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