最近，有部分越南的服務器內存不斷上漲，懷疑是內存泄漏，因為框架提供的內存報告里，C內存和Lua占用內存都不大，和ps里看的差好多。總內存在12G左右，C和Lua的加起來約4G，兩者相差了8G
經過一番排查，排除了混用glibc malloc和jemalloc的可能。於是寫了一個多線程的測試程序，由多個生產者-消費者線程對組成。生產者分配一個隨機大小的內存（在SIZE范圍內），然后memset將內存遍歷一次，再將指針通過管道發給消費者。消費者拿到指針后，讀一下指針的值，然后釋放指針對應內存塊。這個模型模擬了skynet的一個線程分配內存（消息），發給另一個線程消費（釋放）的情況。在沒有設置jemalloc的參數的情況下，這個例程的內存會逐漸漲到一個峰值，然后不再增大，但也不再減少。如果設定了例程里的ABORT_COUNT，過了指定次數后不再進行內存分配，內存過幾個小時也不會下降，這跟線上的情況類似
通過MALLOC_CONF環境變量，設置了dirty_decay_ms:0,muzzy_decay_ms:0以后，內存的峰值變低了，觀察top命令的RES內存，明顯低了不少。將選項換成了background_thread:true，則例程即使不再分配內存，內存占用也會逐漸降低了。dirty_decay_ms表示內存塊從dirty狀態移動到muzzy狀態的時間，muzzy_decay_ms是muzzy狀態到釋放給系統的時間。設為0以后行為會不一樣，比如我兩個參數都設置10000ms，並不是20秒后就會還給系統。。
往后打算設置一下background_thread:true，讓內存不再使用時慢慢還給系統，避免OOM Killer找上門來殺進程