sence：python中使用subprocess.Popen(cmd, stdout=sys.STDOUT, stderr=sys.STDERR, shell=True) ，stdout, s ...

一、發現問題 下面是線上機器的cpu使用率，可以看到從4月8日開始，隨着時間cpu使用率在逐步增高，最終使用率達到100%導致線上服務不可用，后面重啟了機器后恢復。 二、排查思路 簡單分析下可能出問題的地方，分為5個方向： 1.系統本身代碼問題 2.內部下游系統的問題導致的雪崩 ...

一、發現問題 下面是線上機器的cpu使用率，可以看到從4月8日開始，隨着時間cpu使用率在逐步增高，最終使用率達到100%導致線上服務不可用，后面重啟了機器后恢復。 二、排查思路 簡單分析下可能出問題的地方，分為5個方向： 1.系統本身代碼問題 2.內部下游系統的問題導致的雪崩 ...

轉貼：http://my.oschina.net/flashsword/blog/205266 本文是一次線上OOM故障排查的經過，內容比較基礎但是真實，主要是記錄一下，沒有OOM排查經驗的同學也可以參考。 現象 我們之前有一個計算作業。最近經常出現不穩定，無法正常響應的情況。具體表現 ...

近期遇到一個堆外內存導致swap飆高的問題，這類問題比較罕見，因此將整個排查過程記錄下來了 現象描述 最近1周線上服務器時不時出現swap報警（swap超過內存10%時觸發報警，內存是4G，因此swap超過400M會觸發報警），每次都是童鞋們通過重啟tomcat解決的；但導致的根本原因 ...

剛入職公司接觸到的第一個項目，應用架構比較簡單和無理 1、業務是推送數據到ldap數據庫，應用是java寫的 2、架構是兩台mysql主主復制，haproxy做兩台mysql的負載（ps：由於應用代碼的邏輯，導致haproxy只能把流量切換到一台數據庫），keepalived做高可用 ...

起因：周末測試發現線上mq消息積壓了十幾萬的消息，如下圖所示 每個隊列幾萬的消息，立即采取緊急措施，將隊列下線重新上線。 處理積壓消息的量，調用量起來了，很快消息積壓解決了。開始事件復盤。 首先分析是否是消息消費能力跟不上消息產生原因，看入口消息，QPS是29.6 消息消費 ...

​ 標題采自：英雄聯盟-瑞文：斷劍重鑄之日，騎士歸來之時！ 斷劍 ​ 前兩天早上在擠地鐵的時候看到小組群里，主管發了好多消息，打開來一看，說是XX項目自從22號發版后，每天晚上就瘋狂Full GC ...