背景

近期一個大版本上線后，Python編寫的api主服務使用內存有較明顯上升，服務重啟后數小時就會觸發(fā)機器的90%內存占用告警，分析后發(fā)現了本地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值應該可以保證其合理內存的合理使用，而這次新版本發(fā)布新增了類似如下兩個個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，其緩存的是業(yè)務內部使用的user_id到用戶app上可見的display_id的映射關系，該映射關系在用戶創(chuàng)建時即生成固定不變，可以設置較長期時間，如果同時有效的對象數超過的maxlen，這個LocalCache直接就等價于一個LRU了，對象釋放可以完全依賴deque的先進先出淘汰機制。
在最開始評估其占用內存時考慮了以下因素:

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

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

LocalCache占用內存的正確評估

線上出現內存問題后，嘗試使用tracemalloc分析了線上服務的內存分配情況，發(fā)現很多內存都集中于LocalCache這塊，于是結合實際重新評估這個內存占用，發(fā)現了以下問題：

str與float的內存占用評估錯誤，即便str本身len只有10個字符,其占用內存其實是遠大于10的，而float并不是占用8字節(jié)而是24字節(jié)，如下代碼可驗證：

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字節(jié)，而如果存入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字節(jié)，這樣一評估，最終這兩個cache單主機上需要占用的最大且肯定會達到的內存大小變成了: 700 * 500000 * 4 * 2 / 1024/1024 = 2.67GB，是之前錯誤評估值的6倍==！這樣一算主機上的內存就不夠用了。

后續(xù)處理

結合實際正確評估內存占用后，總結以下LocalCache使用原則：

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

針對api服務使用的多處LocalCache按照以上原則進行優(yōu)化后，其占用的總內存量下降了超過3GB。

總結

在初版評估cache內存占用時，用了想當然評估法，而沒有實測每個類型、對象的實際占用大小，導致評估值遠小于實際值。
對于LocalCache的對象回收原理未深度理解，一直想當然認為只要過了有效時間其對象即會被回收掉，沒有認識到其回收完全依賴于deque。
又一次想當然造成的問題。

到此這篇關于Python本地cache不當使用導致內存泄露的問題分析與解決的文章就介紹到這了,更多相關Python內存泄露內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論