作者：田逸（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掛接方式對性能的影響也比較大。