nginx進程狀態D

昨天跟一朋友聊天，說到運維職業規劃問題感概良多，以前大家做運維，終極目標就是做到運維架構師什麼的，說白了就是什麼都得了解，什麼環境用什麼產品，解決什麼問題，什麼高可用，高性能，包括分散式文件系統，你都得知道一二；再後來運維的活細化了（特別是大公司），又開始細分系統運維和應用運維、甚至包括大數據運維，從結構上看，職業分類越來越細，也更加的專註某一領域，運維開發這一職位也隨之而出現（當然這也少不了培訓機構的瘋狂攬生造勢的功勞），然後這二年，又開始持續集成開發理念，然後你會看到各大公司招聘又開始要求了解docker k8s之類的，還有甚至要求具有devops理念，目不暇接！作為小公司運維的我看在眼裡急在心裡，都不知道如何選擇和規劃，再加之年紀大了，經歷有限，真心有點力不從心，聊到最後總之一句話，要不停的學習新的知識，另外一點，就是要不斷加強處理問題的能力，經驗是你最大的財富和就業的競爭力，但千萬不能經驗主義，做到具體問題具體分析，根據實際情定位問題，不能根據經驗臆測問題，下面我們一起看看nginx被Ｄ住的一則分析定位：

曾經有一段時間，我們的某個網站nginx請求為0的情況，截圖如下：

為了更精確的捕捉問題，我們在出現請求為0的時候，打開終端或者ps進行狀態捕捉，讓我們發現：

那麼為什麼nginx狀態全部被Ｄ住了呢？弄清這個問題，我們首先要弄明白D狀態是怎麼回事，關於D狀態說明

man ps可以找到一些說明，你也可以google去查一下具體描述

Linux進程有兩種睡眠狀態，一種是interruptible sleep,處在這種睡眠狀態的進程是可以通過給它發送信號來喚醒的，比如發送HUP信息給nginx的master進程是可以讓nginx重新載入配置文件而不需要重啟nignx進程的；另外一種睡眠狀態是uninterruptible sleep,處理於這種狀態的進程不接受外來的任何信號，在這種狀態下無法使用kill殺死這些處於D狀態的進程的，無論你是用kill -9還是kill -15，因為它們已經不受這些信號的支配了。只能通過重啟系統解決，因為在出現問題這個過程，我曾試圖重啟nginx, 結果是並無任何反應。

Nginx為什麼會被置於uninterruptible sleep狀態呢？

處於這種狀態的進程通常是在等待IO，比如磁碟IO、網路IO或其他外設IO；如果nginx在等待的IO在較長時間內沒有響應，那麼很不幸，就像我們上面的截圖一樣，進入D狀態, 試想一個已經因等待IO而uninterruptible sleep的進程，還會處理請求嗎？已經不受任何信號支配了，此時你重啟或者關閉都不會得到響應，直至等待IO恢復，nginx才會恢復響應，那麼截圖請求又恢復就說得通了，當然，這後面還需要進一步驗證來證明想法，我們這個問題是當時用了某雲商的分散式文件系統，該產品類似GlusterFS，對小文件支持的極差，然後我們的站點，確實也是小文件巨多的那種，為了排查問題所在，我們將分散式文件系統換成單硬碟進行為期兩周的測試。結果怎麼樣這裡就不說了！

運維處理問題程序：一定要以實際為準，千萬不要根據經驗主觀臆測！依靠紮實的專業知識，細心、分析、推斷、驗證！