線上功能遇見記憶體洩漏事故，引發玩家卡頓等異常現象，不得不手動重啟發生記憶體洩漏的伺服器程序來釋放記憶體，原因是由於stl容器使用不當。記憶體洩漏對於c++程式設計師來說可能是乙個老生常談的問題了，當專案工程比較龐大複雜時，很容易產生記憶體洩漏問題且定位困難。程式發生記憶體洩漏通常第一時間會聯想到指標所指向的記憶體沒有釋放，從而會去關注**裡面所用到指標，進而去一一排查指標，追蹤記憶體洩漏的原因。這種思路沒有問題，也能查出來大多數的記憶體洩漏問題。另一方面，對於c++程式設計師來說，使用stl容器會比較多，使用stl容器不當也會造成記憶體洩漏問題，如下例所示，使用memset初始化帶有string或者vector型別的結構體資料時引發記憶體洩漏，所以對於容器的使用還需小心謹慎!!!
#include
#include
#include
#define bzero(a, b) memset(a, 0, b)
struct test_bzero_t
};int main()
return 0;
}以上**在vs2017上測試通過，當開啟(1)處注釋**時，記憶體監控器顯示該程序記憶體消耗不斷飆公升，由此可見發生了嚴重的記憶體洩漏!!! 當注釋(1)處**，使用(2)處**進行初始化資料時，則不會發生記憶體洩漏。之所以發生這種現象是因為使用memset
初始化結構體中的容器會破壞容器的資料結構(string和vector的底層實現通常都是動態陣列即會存在乙個指標變數與乙個表示資料長度的變數)，由此產生了***，導致容器資料結構中的指標置空，從而無法釋放記憶體。
本文拋磚引玉，僅為追蹤記憶體洩漏問題提供一些思考。
記一次dirty ratio引起的線上事故
磁碟 75 最終累計到100 load1 遠遠 8 cpu mem 85 kernel報錯如下 預設情況下，linux會最多使用40 的可用記憶體作為檔案系統快取。當超過這個閾值後，檔案系統會把將快取中的記憶體全部寫入磁碟，導致後續的io請求都是同步的。將快取寫入磁碟時，有乙個預設120秒的超時時間...
發生線上事故這麼辦
值班人員快速查詢問題，定位不到的時候，立馬通知所有相關人員 嘗試恢復系統，最終要的不是修復bug，而是減少故障的影響範圍，並最快的修復問題 建議以使用者功能為索引的服務和資源的呼叫關係圖。為關係圖中的，各個業務定立關鍵指標和一套運維流程和工具，最好有運維系統監控系統 設定故障的等級和處理方式 故障演...
我的物聯網專案 七 前期線上事故
一 mqtt連線數報警 有天下午快下班的時候，突然mqtt不斷報警，手機上5秒一次收到報警簡訊，提示mqtt連線數已經超標 用阿里雲的產品感覺這塊的預警功提示的還是蠻及時 因為當初也有一些搖搖車在做測試，頻繁的使用到mqtt，所以當時也沒太在意，叫測試人員先停一下在做測試 這個裡面很尷尬，搖搖車掃碼...