簡訊的生產環境伺服器， cpu 佔用率過高，瘋狂報警，應該是你們昨天上線看門狗導致的（看門狗：守護簡訊服務的監控應用，後續有機會再進行分享）。
沒錯，昨天確實給簡訊服務裝上了看門狗。但是看門狗服務肯定不會有問題（作為程式猿們，潛意識都堅信自己寫的**永無 bug），主要因為測試環境都沒有此現象。
難道是測試妹子沒測試到位？難道線上簡訊應用自身出現了問題？
生產無小事，小事更不能忽視。迅速開啟電腦，開啟 vpn ，遠端登上簡訊生產伺服器，開始 2w1h 三板斧診斷之旅。
輸入 top 命令一**竟，我勒個去，不看不知道一看嚇一跳，pid 為 1878 的病號，cpu 占用居然 200% 多。
pid 為 1878 的病號到底是誰，難道真是我昨天上線的看門狗 ？
雖然久經職場，但是排查生產問題時，內心還是比較忐忑，畢竟生產無小事。說時遲，那時快，只見猿外乙個命令輸入 ps -ef | grep 1878 ，定睛一看，原來是簡訊服務本尊在作祟，心裡一下子平緩了不少。鍋找到了屬主
為什麼 1878 號病人占用 cpu 會這麼高呢？
輸入 jstack -l 1878 >> 1878號病歷.log ，於是便得到乙份 1878 號病人的病歷詳情單。到底 1878 號病人的哪個部位出了問題呢？
話沒說完，只見猿外，又在控制台診斷儀器上，輸入乙個 top -hp 1878 命令，白板黑字，把 1878 號病人的器官資訊全部列了出來。
看到結果，甚是一驚，pid 代號為 8721 的器官占用 cpu 100% 多。疑惑油然而生，這個 pid 代號 為 8721 的器官是啥，是頭、是眼睛、還是胳膊腿呢？這些器官展示的 pid 列都是暱稱，都這麼善於偽裝，如何揭露它的真面目呢？
還好猿外有高招，借助照妖鏡演算法，熟練的輸入 printf "%x\n" 8721 ，果真使得代號為 8721 的器官，現了真身，真實身份居然是 2211 的呼吸道，怪不得病號一直氣喘吁吁，上氣不接下氣。
到這一步還無法對症下藥啊，還需要進一步確診 2211 的呼吸道到底出了什麼么蛾子，導致 1878 號病人一直氣喘吁吁，上氣不接下氣？
只見黑乎乎的控制台診斷儀器上，猿外再次飛一般的在輸入 grep 2211 -a20 1878號病歷.log，診斷結果隨之顯示在診斷儀器上。
看到診斷結果心裡樂了一下，一眼就看出是高併發情況下用了 hashmap 的問題（請猿友們自行尋找谷哥、度娘，就不在此深入展開啦），終於撥開雲霧見青天。
1、病號是誰？（who）
2、病號**出了問題？（where）
3、捉得病根、便可拿出醫藥箱，對症下藥啦。（how）
作為運維，工作中難免會遇到不少類似這樣的問題，面對問題，你如果像無頭蒼蠅一樣亂撞，撞得頭破血流依然不知道緣由，在背鍋即將成為現實時，那就不妨試試的 2w1h 三板斧的診斷方式，說不定會幫你快速定位、解決線上問題，畢竟快速的解決生產問題會把損失降到最低。
簡訊的生產環境伺服器， cpu 佔用率過高，瘋狂報警，應該是你們昨天上線看門狗導致的（看門狗：守護簡訊服務的監控應用，後續有機會再進行分享）。
沒錯，昨天確實給簡訊服務裝上了看門狗。但是看門狗服務肯定不會有問題（作為程式猿們，潛意識都堅信自己寫的**永無 bug），主要因為測試環境都沒有此現象。
難道是測試妹子沒測試到位？難道線上簡訊應用自身出現了問題？
生產無小事，小事更不能忽視。迅速開啟電腦，開啟 vpn ，遠端登上簡訊生產伺服器，開始 2w1h 三板斧診斷之旅。
輸入 top 命令一**竟，我勒個去，不看不知道一看嚇一跳，pid 為 1878 的病號，cpu 占用居然 200% 多。
pid 為 1878 的病號到底是誰，難道真是我昨天上線的看門狗 ？
雖然久經職場，但是排查生產問題時，內心還是比較忐忑，畢竟生產無小事。說時遲，那時快，只見猿外乙個命令輸入 ps -ef | grep 1878 ，定睛一看，原來是簡訊服務本尊在作祟，心裡一下子平緩了不少。鍋找到了屬主
為什麼 1878 號病人占用 cpu 會這麼高呢？
輸入 jstack -l 1878 >> 1878號病歷.log ，於是便得到乙份 1878 號病人的病歷詳情單。到底 1878 號病人的哪個部位出了問題呢？
話沒說完，只見猿外，又在控制台診斷儀器上，輸入乙個 top -hp 1878 命令，白板黑字，把 1878 號病人的器官資訊全部列了出來。
看到結果，甚是一驚，pid 代號為 8721 的器官占用 cpu 100% 多。疑惑油然而生，這個 pid 代號 為 8721 的器官是啥，是頭、是眼睛、還是胳膊腿呢？這些器官展示的 pid 列都是暱稱，都這麼善於偽裝，如何揭露它的真面目呢？
還好猿外有高招，借助照妖鏡演算法，熟練的輸入 printf "%x\n" 8721 ，果真使得代號為 8721 的器官，現了真身，真實身份居然是 2211 的呼吸道，怪不得病號一直氣喘吁吁，上氣不接下氣。
到這一步還無法對症下藥啊，還需要進一步確診 2211 的呼吸道到底出了什麼么蛾子，導致 1878 號病人一直氣喘吁吁，上氣不接下氣？
只見黑乎乎的控制台診斷儀器上，猿外再次飛一般的在輸入 grep 2211 -a20 1878號病歷.log，診斷結果隨之顯示在診斷儀器上。
看到診斷結果心裡樂了一下，一眼就看出是高併發情況下用了 hashmap 的問題（請猿友們自行尋找谷哥、度娘，就不在此深入展開啦），終於撥開雲霧見青天。
1、病號是誰？（who）
2、病號**出了問題？（where）
3、捉得病根、便可拿出醫藥箱，對症下藥啦。（how）
作為運維，工作中難免會遇到不少類似這樣的問題，面對問題，你如果像無頭蒼蠅一樣亂撞，撞得頭破血流依然不知道緣由，在背鍋即將成為現實時，那就不妨試試的 2w1h 三板斧的診斷方式，說不定會幫你快速定位、解決線上問題，畢竟快速的解決生產問題會把損失降到最低。
一次非同步處理
首發於 一次非同步處理 今天回憶了一下在做專案的時候遇到的乙個小問題。就是當兩個介面請求的資料相互沒有影響時，而你卻需要這兩個介面的所有資料，你會怎麼做呢？當我處理這個的時候想到的第乙個方案是這樣的。由於兩個介面相互沒有影響，我使用了乙個中間量進行判斷。是這樣寫的。var flag 2 請求資料1 ...
再幫CPU節省一次資源
今天下午在寫象棋程式時想在對話方塊上顯示系統時間，出於個性化，我採用了顯示，進行簡單的換算，將時鐘的十分位和個位以及分鐘的十分位和個位分別擷取出來，然後將每位數字對應一張我用ps做好了的數字，然後用timer按普通方法成功實現了，也就是說每隔一秒種更新一次時間的顯示以便和系統時間吻合，從執行來看發現...
一次SYN攻擊處理
公司有oa布置在阿里雲伺服器上，資料庫為了方便備份布置在了本地。最近幾天據同事反映，oa訪問速度很慢，測試了雲伺服器和本地伺服器的網路都是正常的，一時查不到原因。後來想到可能問題會不會出在資料庫的連線上導致阿里雲伺服器訪問本地資料庫速度慢引起oa的訪問速度慢。遂去本地資料庫伺服器 開啟cmd，輸入命...