715
Load高，CPU idle很高，這情況太詭異了
Load很高，CPU使用率很低的詭異情況
第一次碰到這種Case：物理機的Load很高，CPU使用率很低
先看CPU、Load情況
如圖一：
vmstat顯示很有多任務等待排隊執行（r）top都能看到Load很高，但是CPU idle 95%以上
這個現象不太合乎常規，也許是在等磁盤IO、也許在等網絡返回會導致CPU利用率很低而Load很高
貼個vmstat 說明文檔（圖片來源於網絡N年了，找不到出處）
檢查磁盤狀態，很正常（vmstat 第二列也一直為0）
再看Load是在5號下午15：50突然飆起來的：
同一時間段的網絡流量、TCP連接相關數據很平穩：
所以分析到此，可以得出：**Load高跟磁盤、網絡、壓力都沒啥關係**
物理機上是跑的Docker，分析了一下CPUSet情況：
發現基本上所有容器都綁定在CPU1上（感謝 @辺客 發現這個問題）
進而檢查top每個核的狀態，果然CPU1 的idle一直為0
看到這裏大致明白了，雖然CPU整體很閑但是因為很多進程都綁定在CPU1上，導致CPU1上排隊很長，看前麵tsar的--load負載截圖的 等待運行進程排隊長度（runq）確實也很長。
物理機有32個核，如果100個任務同時進來，Load大概是3，這是正常的。如果這100個任務都跑在CPU1上，Load還是3（因為Load是所有核的平均值）。但是如果有源源不斷的100個任務進來，前麵100個還沒完後麵又來了100個，這個時候CPU1前麵隊列很長，其它31個核沒事做，這個時候整體Load就是6了，時間一長很快Load就能到幾百。
這是典型的瓶頸導致積壓進而高Load。
為什麼會出現這種情況
檢查Docker係統日誌，發現同一時間點所有物理機同時批量執行docker update 把幾百個容器都綁定到CPU1上，導致這個核忙死了，其它核閑得要死（所以看到整體CPU不忙，最忙的那個核被平均掩蓋掉了），但是Load高（CPU1上排隊太長，即使平均到32個核，這個隊列還是長，這就是瓶頸啊）。
如下Docker日誌，Load飆升的那個時間點有人批量調docker update 把所有容器都綁定到CPU1上：
檢查Docker集群Swarm的日誌，發現Swarm沒有發起這樣的update操作，似乎是每個Docker Daemon自己的行為，誰觸發了這個CPU的綁定過程的原因還沒找到，求指點。
手動執行docker update, 把容器打散到不同的cpu核上，恢複正常：
總結
- 技術拓展商業邊界，同樣技能、熟練能力能拓展解決問題的能力。 開始我注意到了Swarm集群顯示的CPU綁定過多，同時也發現有些容器綁定在CPU1上。所以我嚐試通過API： GET /containers/json 拿到了所有容器的參數，然後搜索裏麵的CPUSet，結果這個API返回來的參數不包含CPUSet，那我隻能挨個 GET /containers/id/json, 要寫個循環，偷懶沒寫，所以沒發現這個問題。
- 這種多個進程綁定到同一個核然後導致Load過高的情況確實很少見，也算是個教訓
- 自己觀察top 單核的時候不夠仔細，隻是看到CPU1 的US 60%，沒留意idle，同時以為這個60%就是偶爾一個進程在跑，耐心不夠（主要也是沒意識到這種極端情況，疏忽了）
最後更新：2017-06-12 16:32:07