一次Python本地cache不当使用导致的内存泄露

小小童 · 发表于 2023-8-30 02:35:01

背景

近期一个大版本上线后，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。
总结

在初版评估cache内存占用时，用了想当然评估法，而没有实测每个类型、对象的实际占用大小，导致评估值远小于实际值。
对于LocalCache的对象回收原理未深度理解，一直想当然认为只要过了有效时间其对象即会被回收掉，没有认识到其回收完全依赖于deque。
又一次想当然造成的问题。
转载请注明出处，原文地址： https://www.cnblogs.com/AcAc-t/p/python_local_cache_usage.html
参考

https://docs.python.org/3.8/library/tracemalloc.html
https://www.cnblogs.com/AcAc-t/p/python_weakref_study.html
https://docs.python.org/3.8/library/collections.html#collections.deque
https://www.cnblogs.com/AcAc-t/p/python_local_cache_usage.html
https://docs.python.org/3.8/library/sys.html?highlight=getsizeof

来源:https://www.cnblogs.com/AcAc-t/p/python_local_cache_usage.html
免责声明：由于采集信息均来自互联网，如果侵犯了您的权益，请联系我们【E-Mail:cb@itdo.tech】我们会及时删除侵权内容，谢谢合作！