ansible部署k8s時(shí)，跑到docker相關(guān)劇本，在reload docker卡住了，然后去到對(duì)應(yīng)機(jī)器查看systemctl status docker，報(bào)錯(cuò)Failed to get properties: Connection timed out.
然后發(fā)現(xiàn)systemctl不好用了，網(wǎng)上找的重啟dbus什么的，都不好用，只能重啟服務(wù)器。
然后在messages日志里看到有如下報(bào)錯(cuò)

image.png

這個(gè)問(wèn)題是怎么出現(xiàn)的，怎么解決請(qǐng)參考下面鏈接
https://www.aikaiyuan.com/11829.html

一般情況下Linux寫(xiě)磁盤(pán)時(shí)會(huì)用到緩存，這個(gè)緩存大概是內(nèi)存的40%，只有當(dāng)這個(gè)緩存差不多用光時(shí)，系統(tǒng)才會(huì)將緩存中的內(nèi)容同步寫(xiě)到磁盤(pán)中。但是操作系統(tǒng)對(duì)這個(gè)同步過(guò)程有一個(gè)時(shí)間限制，就是120秒。如果系統(tǒng)IO比較慢，在120秒內(nèi)搞不定，那就會(huì)出現(xiàn)這個(gè)異常。這通常發(fā)生在內(nèi)存很大的系統(tǒng)上。
原因找到了，怎么解決呢？網(wǎng)上也有一些方案，比如

1. /sbin/sysctl -w vm.dirty_ratio=10
2. echo noop > /sys/block/sda/queue/scheduler
3. /sbin/sysctl -w kernel.hung_task_timeout_secs = 0
   第一個(gè)方案是調(diào)整緩存占內(nèi)存的比例，降到10%，這樣的話(huà)較少的緩存內(nèi)容會(huì)被比較頻繁地寫(xiě)到硬盤(pán)上，IO寫(xiě)會(huì)比較平穩(wěn)
   第二個(gè)方案是修改系統(tǒng)的IO調(diào)度策略，使用noop的方式，這是一種基于FIFO的最簡(jiǎn)單的調(diào)度方式
   第三個(gè)方案是不讓系統(tǒng)有那個(gè)120秒的時(shí)間限制，希望就是我慢就慢點(diǎn)，你等著吧，實(shí)際上操作系統(tǒng)是將這個(gè)變量設(shè)為長(zhǎng)整形的最大值。
   這三個(gè)方案好像都很有道理，應(yīng)該能搞定這個(gè)吧？但是，往往事與愿違，這三種方案經(jīng)QA驗(yàn)證后一個(gè)也沒(méi)發(fā)揮作用，問(wèn)題依舊偶爾出現(xiàn)。

1、內(nèi)核hung task檢測(cè)機(jī)制由來(lái)
我們知道進(jìn)程等待IO時(shí)，經(jīng)常處于D狀態(tài)，即TASK_UNINTERRUPTIBLE狀態(tài)，處于這種狀態(tài)的進(jìn)程不處理信號(hào)，所以kill不掉，如果進(jìn)程長(zhǎng)期處于D狀態(tài)，那么肯定不正常，原因可能有二：
1）IO路徑上的硬件出問(wèn)題了，比如硬盤(pán)壞了(只有少數(shù)情況會(huì)導(dǎo)致長(zhǎng)期D，通常會(huì)返回錯(cuò)誤)；
2）內(nèi)核自己出問(wèn)題了。
這種問(wèn)題不好定位，而且一旦出現(xiàn)就通常不可恢復(fù)，kill不掉，通常只能重啟恢復(fù)了。
內(nèi)核針對(duì)這種開(kāi)發(fā)了一種hung task的檢測(cè)機(jī)制，基本原理是：定時(shí)檢測(cè)系統(tǒng)中處于D狀態(tài)的進(jìn)程，如果其處于D狀態(tài)的時(shí)間超過(guò)了指定時(shí)間(默認(rèn)120s，可以配置)，則打印相關(guān)堆棧信息，也可以通過(guò)proc參數(shù)配置使其直接panic。
2、hung task相關(guān)配置
1）設(shè)置timeout時(shí)間：
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