ansible部署k8s時策菜，跑到docker相關(guān)劇本晶疼，在reload docker卡住了，然后去到對應(yīng)機器查看systemctl status docker又憨，報錯Failed to get properties: Connection timed out.
然后發(fā)現(xiàn)systemctl不好用了翠霍，網(wǎng)上找的重啟dbus什么的，都不好用蠢莺，只能重啟服務(wù)器寒匙。
然后在messages日志里看到有如下報錯
主要是這個問題hung_task_timeout_secs，然后在docker官網(wǎng)找到了這個System unresponsive with 'kernel: INFO: task systemd:1 blocked for more than 120 seconds.' following Docker daemon shutdown
這個問題是怎么出現(xiàn)的躏将，怎么解決請參考下面鏈接
https://www.aikaiyuan.com/11829.html
一般情況下Linux寫磁盤時會用到緩存锄弱，這個緩存大概是內(nèi)存的40%，只有當(dāng)這個緩存差不多用光時祸憋，系統(tǒng)才會將緩存中的內(nèi)容同步寫到磁盤中会宪。但是操作系統(tǒng)對這個同步過程有一個時間限制，就是120秒蚯窥。如果系統(tǒng)IO比較慢狈谊，在120秒內(nèi)搞不定，那就會出現(xiàn)這個異常沟沙。這通常發(fā)生在內(nèi)存很大的系統(tǒng)上河劝。
原因找到了，怎么解決呢矛紫？網(wǎng)上也有一些方案赎瞎，比如
- /sbin/sysctl -w vm.dirty_ratio=10
- echo noop > /sys/block/sda/queue/scheduler
- /sbin/sysctl -w kernel.hung_task_timeout_secs = 0
第一個方案是調(diào)整緩存占內(nèi)存的比例，降到10%颊咬，這樣的話較少的緩存內(nèi)容會被比較頻繁地寫到硬盤上务甥，IO寫會比較平穩(wěn)
第二個方案是修改系統(tǒng)的IO調(diào)度策略牡辽，使用noop的方式，這是一種基于FIFO的最簡單的調(diào)度方式
第三個方案是不讓系統(tǒng)有那個120秒的時間限制敞临，希望就是我慢就慢點态辛，你等著吧，實際上操作系統(tǒng)是將這個變量設(shè)為長整形的最大值挺尿。
這三個方案好像都很有道理奏黑，應(yīng)該能搞定這個吧？但是编矾，往往事與愿違熟史，這三種方案經(jīng)QA驗證后一個也沒發(fā)揮作用，問題依舊偶爾出現(xiàn)窄俏。
1蹂匹、內(nèi)核hung task檢測機制由來
我們知道進(jìn)程等待IO時，經(jīng)常處于D狀態(tài)凹蜈，即TASK_UNINTERRUPTIBLE狀態(tài)限寞，處于這種狀態(tài)的進(jìn)程不處理信號，所以kill不掉仰坦，如果進(jìn)程長期處于D狀態(tài)昆烁，那么肯定不正常，原因可能有二：
1）IO路徑上的硬件出問題了缎岗，比如硬盤壞了(只有少數(shù)情況會導(dǎo)致長期D静尼，通常會返回錯誤)；
2）內(nèi)核自己出問題了传泊。
這種問題不好定位鼠渺，而且一旦出現(xiàn)就通常不可恢復(fù)，kill不掉眷细，通常只能重啟恢復(fù)了拦盹。
內(nèi)核針對這種開發(fā)了一種hung task的檢測機制，基本原理是：定時檢測系統(tǒng)中處于D狀態(tài)的進(jìn)程溪椎，如果其處于D狀態(tài)的時間超過了指定時間(默認(rèn)120s普舆，可以配置)，則打印相關(guān)堆棧信息校读，也可以通過proc參數(shù)配置使其直接panic沼侣。
2、hung task相關(guān)配置
1）設(shè)置timeout時間：
echo xx > /proc/sys/kernel/hung_task_timeout_secs
xx單位為s歉秫。
2）設(shè)置hung task后是否觸發(fā)panic
echo 1 > /proc/sys/kernel/hung_task_panic
