問題緣起: 當我習慣性地用top檢視任務執行狀態時，發現我執行的100個任務，只有3個在執行，其他都在摸魚狀態。同時發現我的任務程序都是"d"狀態(未截圖)，而不是r(執行)狀態。
這個時候，我直覺上感覺這是硬碟讀寫除了問題，於是我開始檢索查詢相關工具去驗證我的猜想
1.先用的是iostat -x 2 10，如果%util接近100%說明產生的i/o請求太多，i/o系統滿負荷，%idle小於70%，io壓力就很大。
2.從上圖明顯發現我的io壓力過大。當然作為科研人員，我們都知道我們需要多個證據才能證實自己的猜想，於是進一步用iotop, 發現有許多程序的io居然是99%.
3.既然確定伺服器效能下降的原因是io。那麼下一步就是找到導致磁碟壓力過大的真兇。用dstat --top-bio-adv找到那個程序占用io最多， 此處發現是jdb2/sda1-8 的寫出資料超多
利用關鍵字"jdb2/sda1-8"經過搜尋，發現很多人都遇到這種情況，
剛好，我的伺服器是raid，又剛好我今天改動了mysql。但是直覺告訴我，應該不是這兩個問題，因為我雖然改了mysql的配置檔案，但是我基本不用mysql, 所以排除這個可能。
但是，目前我已經順利確認就是"jdb2/sdax-y"的問題(x表示是分割槽)，於是我就主要檢索了jdb2
jbd2的全稱是journaling block driver 。這個程序實現的是檔案系統的日誌功能，磁碟使用日誌功能來保證資料的完整性。這個需要評估一下安全和效能哪個更重要，對於乙個應用伺服器來說，網路上的人提供了如下三種解決方案:並不儲存重要的使用者資料，只是實現業務邏輯。如果是資料庫的話，就需要考慮啟動磁碟寫入的完整性檢查。但是現在大部分系統在業務和架構層面已經考慮了業務完整性。所以為效能計，這裡並不是非常有必須啟動日誌功能。
當然這些方案，我乙個都沒有採納，因為我突然想到今天伺服器上似乎執行了許多io操作很頻繁的程式，jdb2的特點就是犧牲了效能保證了資料完整性，也就是說是我執行的程式太多讓jdb2忙不過來了。
因此我的最終解決方案就是，用kill把所有當前執行的高io程式都乾掉。最後解決了問題。
伺服器運維
運維 網際網路運維，通常屬於技術部門，與研發 測試 系統管理同為網際網路產品技術支撐的4大部門，這個劃分在國內和國外以及大小公司間都會多少有一些不同。產品的整個生命週期裡運維的職責重要而廣泛，但運維工程師們的職責不僅限於這部分工作，還需要總結工作中遇到的問題，抽取出相關的技術方向 研發相關的工具和平...
python運維伺服器
好久沒有寫東西了.一直做伺服器開發需要寫一些指令碼來控 務器的啟動.本來windows自帶了任務計畫,但不是特別方便,還是用python寫了一下.需求 在固定的時間啟動伺服器 先看源 def start process date cwd os.getcwd global list threads g...
伺服器運維簡介
一 認識伺服器 良知知彼才氣百戰不殆，假如對本身維護的伺服器都不相識，何故能正確辦理伺服器宕機 補丁安裝，裂痕修復等問題。1.伺服器操縱系統範例，版本，補丁版本 2.伺服器硬碟利用率 3.伺服器執行業務的環境 4.伺服器網路設定環境等。二 按期查抄 1.伺服器電源狀態查抄 2.伺服器電扇狀態查抄 3...