一次Python本地cache不當使用導致的記憶體泄露

數據類型是編程中的重要概念。數據類型指定了變數值的大小和類型。 Go是靜態類型的，這意味著一旦變數類型被定義，它只能存儲該類型的數據。 Go有三種基本數據類型： - bool：表示布爾值，要麼是true，要麼是false。 - 數值型：表示整數類型、浮點數值和複數類型。 - string：表示字元串 ...

背景

近期一個大版本上線後，Python編寫的api主服務使用記憶體有較明顯上升，服務重啟後數小時就會觸發機器的90%記憶體占用告警，分析後發現了本地cache不當使用導致的一個記憶體泄露問題，這裡記錄一下分析過程。

問題分析

LocalCache實現分析

該cache大概實現代碼如下：

class LocalCache():
    notFound = object() # 定義cache未命中時返回的唯一對象
    # list dict等本身不支持弱引用，但其子類支持，這裡包裝下
    class Dict(dict):
        def __del__(self):
            pass

    def __init__(self, maxlen=10): # maxlen指定最多緩存的對象個數
        self.weak = weakref.WeakValueDictionary() # 存儲緩存對象弱引用的dict
        self.strong = collections.deque(maxlen=maxlen) # 存儲緩存對象強引用的deque

    # 從緩存dict中查找對應key的對象，若已過期或不存在則返回notFound
    def get_ex(self, key):
        value = self.weak.get(key, self.notFound)
        if value is not self.notFound:
            expire = value['expire']
            if self.nowTime() > expire:
                return self.notFound
            else:
                return value['result']
        return self.notFound

    # 設置kv到緩存dict中，並設置其過期時間
    def set_ex(self, key, value, expire):
        self.weak[key] = strongRef = LocalCache.Dict({'result': value, 'expire': self.nowTime()+expire})
        self.strong.append(strongRef)

如上述代碼，該LocalCache核心在於一個存儲弱引用的weakref.WeakValueDictionary對象與存儲強引用的deque對象（Python中弱引用與強引用介紹可以參見這篇文章--Python中的弱引用與基礎類型支持情況探究），LocalCache實例化時可以指定最大緩存的對象個數。使用set_ex方法可以設置新的緩存kv，get_ex則獲取指定key的緩存對象，如果key不存在或者已過期則返回notFound。
該LocalCache通過deque在達到maxlen時按先進先出的順序移除隊列元素，而一旦對象的所有強引用被移除後，WeakValueDictionary的特性則保證了對應對象的弱引用也會直接從dict中被移除出去，如此即實現了一個簡單的支持過期時間和最大緩存對象數量限制的本地cache。

LocalCache使用占用記憶體的錯誤評估

按照上面的LocalCache原則，理論上只要設置合理的過期時間與maxlen值應該可以保證其合理記憶體的合理使用，而這次新版本發佈新增了類似如下兩個個LocalCache:

id_local_cache0 = LocalCache(500000)
id_local_cache1 = LocalCache(500000)
id_local_cache0.set_ex('user_id_012345678901', 'display_id_ABCDEFGH', 1800)
id_local_cache1.set_ex('display_id_ABCDEFGH', 'user_id_012345678901', 1800)

如上定義了兩個50w大小的cache，其緩存的是業務內部使用的user_id到用戶app上可見的display_id的映射關係，該映射關係在用戶創建時即生成固定不變，可以設置較長期時間，如果同時有效的對象數超過的maxlen，這個LocalCache直接就等價於一個LRU了，對象釋放可以完全依賴deque的先進先出淘汰機制。
在最開始評估其占用記憶體時考慮了以下因素:

單個k、v對 user_id最多20位元組，display_id最多8位元組，加上要存入的過期時間float欄位8位元組，總大小20+8+8=36，加上一些額外花銷最多100位元組
最大50w限制記憶體占用： 500000 * 100/1024 = 47.6MB
線上api服務為uWSGI框架提供的多進程運行方式，單機4個worker進程，總占用記憶體： 47.6 * 4 = 190MB
兩個LcoalCache占用記憶體： 190MB * 2 = 380MB

按照這個計算一臺主機即便每個進程都緩存滿了50w對象，也就增加不到400MB記憶體占用，何況按照估算同時處於有效期內的緩存對象應該遠小於50w，所以剩餘記憶體應當完全是綽綽有餘的，然而這個評估值其實遠小於實際值。

LocalCache占用記憶體的正確評估

線上出現記憶體問題後，嘗試使用tracemalloc分析了線上服務的記憶體分配情況，發現很多記憶體都集中於LocalCache這塊，於是結合實際重新評估這個記憶體占用，發現了以下問題：

str與float的記憶體占用評估錯誤，即便str本身len只有10個字元,其占用記憶體其實是遠大於10的，而float並不是占用8位元組而是24位元組，如下代碼可驗證：

In [20]: len('0123456789')
Out[20]: 10
In [21]: sys.getsizeof('0123456789')
Out[21]: 59
In [23]: sys.getsizeof(time.time())
Out[23]: 24

即便是一個空dict其占用記憶體也有64位元組，而如果存入kv後則更是急速膨脹為至少232:

In [24]: sys.getsizeof({})
Out[24]: 64
In [26]: sys.getsizeof({'result': {'user_id_012345678901': 'display_id_ABCDEFGH'}, 'expire': time.time()})
Out[26]: 232

無論過期時間設置長短，由於存入該cache的對象資源回收完全是依賴於deque對其存入強引用的移除進行--即便對象按照時間已經過期了，但是只要deque中還存有該對象，對象就不會被回收--所以最終cache中緩存的對象一定會達到設置的maxlen，占用其理論上可占用的最大記憶體。

綜合以上幾點，雖然開始設置的過期時間較短，LocalCache中同時有效的對象數遠小於50w，但最終LocalCache還是會存滿50w的對象，同時實測LocalCache中存入一個對象的平均記憶體大小在700~800位元組，這樣一評估，最終這兩個cache單主機上需要占用的最大且肯定會達到的記憶體大小變成了: 700 * 500000 * 4 * 2 / 1024/1024 = 2.67GB，是之前錯誤評估值的6倍==！這樣一算主機上的記憶體就不夠用了。

後續處理

結合實際正確評估記憶體占用後，總結以下LocalCache使用原則：

maxlen的設置需根據實際數據情況設置為合理值--如最大可能同時有效對象數的1.1 ~ 2.0倍，防止大量過期對象長期占用記憶體而不釋放的情況，check後確認線上代碼就有好幾處maxlen大於其最大有效對象數5~10倍的LocalCache使用。
拆分大對象與小對象同時使用的cache，因為占用幾百位元組的小對象的maxlen設置為1千、1萬甚至10w都合理，但是對於占用幾MB設置十幾MB的對象，maxlen設置>100就已經可能占用掉大量記憶體了。

針對api服務使用的多處LocalCache按照以上原則進行優化後，其占用的總記憶體量下降了超過3GB。