系統執行緩慢
ipmi應該是用於系統管理的遠控程序，雖然這是乙個利用空餘的cpu資源進行一些介面自動調節的任務，但看著佔那麼多的資源還是怕出意外。並且現在已經出了意外 反正不管怎麼樣試試
通過kipmid_max_busy_us值可占用以改變kipmi的排程方式實現降低cpu占用。
臨時降低
echo 100 > /sys/module/ipmi_si/parameters/kipmid_max_busy_us
永久性降低（修改配置檔案，模組/系統重啟生效）
echo "options ipmi_si kipmid_max_busy_us=100">/etc/modprobe.d/ipmi.conf
修改了了之後再檢視下系統負載，果然降低到了正常值。
發現大量gzip壓縮程序和sshd程序占用cpu(最後發現是自己的備份指令碼設定成了每分鐘執行一次，自己把自己給坑了)
還是root使用者啟動的，向同事確認沒人用後直接關了看後續情況
pgrep gzip|xargs kill # 查詢程序pid並kill
400多個php-fpm和nginx，占用cpu百分百
close_wait是被動關閉連線是形成的。根據tcp狀態機，伺服器端收到客戶端傳送的fin，則按照tcp實現傳送ack，因此進入close_wait狀態。但如果伺服器端不執行close()，就不能由close_wait遷移到last_ack，則系統中會存在很多close_wait狀態的連線。此時，可能是系統忙於處理讀、寫操作，而未將已收到fin的連線，進行close。此時，recv/read已收到fin的連線socket，會返回0
伺服器的連線狀態而言，一般有三種比較常見的： established、 time_wait、close_wait。
tcp連線關閉時需要四次握手
a發一條fin(關閉)請求給b，說我要關閉了；
b回應一條ack(確認)請求給a，說我知道了，你關吧，此時b就會進行close_wait狀態；
b傳送一條fin(關閉)請給a，說我要關閉了；
a收到傳送一條ack(確認)訊息說，你關閉吧。
syn表示建立連線，
fin表示關閉連線，
ack表示響應，
httpclient連線池的中建立連線數已經達到了最大數字，不能夠建立新的連線了，已經建立的連線都是在等待關閉（close_wait）的狀態，沒有被放回到可用的連線池中，不能夠用於處理新的連線請求，因而所有的請求都是堵在了從連線池中獲取連線**
通過原理圖，我們知道了close_wait是被動關閉的狀態。什麼意思呢？比如客戶端發了個請求，正常情況下是會收到伺服器響應乙個狀態的，即response。當客戶端讀取了這個返回後，會主動告訴伺服器收到了，關閉連線。
解決辦法
生產環境重大故障
今天廣豐生產環境異常，db session數還沒有滿，客戶端就無法登陸銷售系統。而且就連wls控制台也無法登陸 該問題影響可想而知 最後確定是處理了以下 為了便於分析sql執行狀況，給綜管部提交了乙個提案，對連線測試的選項進行了統一關閉。在 kill掉鎖定的connection源頭後，發現所有的物理...
記一次MySQL生產環境故障處理
在2020年5月15日 凌晨三點，某台生產環境的mysql程序異常，無法連線到資料庫。早上上班開始排查問題並解決。伺服器是windows環境，設定每2天凌晨自動重啟主機，mysql以及其他應用都設定了自動啟動。注 以下所有步驟需要先關閉使用到資料庫的應用程式。檢視系統的計畫任務，發現剛好15日凌晨3...
企業生產環境服務故障排障思路心得總結
這週在部署某企業內部防火牆時，因為沒有與企業內部網路運維工程師進行及時有效的溝通，導致業務遲遲沒有上線。服務始終無法發布到公網上。在經過多次測試與排障之後，終於將業務順利上線。經過長時間在生產環境擔任運維工作，本人也總結了一些排障思路希望可以幫助到苦於排障但又沒有思路的小夥伴們。1.首先你得有故障，...