我有一些关于以下示例中内存使用情况的相关问题。
-
如果我在解释器中运行,
foo = ['bar' for _ in xrange(10000000)]
我的机器上使用的实际内存达到80.9mb
。然后我,
del foo
真实记忆力下降,但仅限于30.4mb
。解释器使用4.4mb
基线那么不释放有什么好处26mb
操作系统的内存?是不是因为Python“未雨绸缪”,认为可能会再次使用那么多内存?
为什么会释放50.5mb
特别是 - 释放的数量是多少?
有没有办法强制Python释放所有已使用的内存(如果你知道你不会再使用那么多内存)?
NOTE这个问题不同于如何在 Python 中显式释放内存?因为这个问题主要涉及即使解释器通过垃圾收集释放对象(使用gc.collect
或不)。
我猜您真正关心的问题是:
有没有办法强制Python释放所有已使用的内存(如果你知道你不会再使用那么多内存)?
不,那里没有。但有一个简单的解决方法:子进程。
如果您需要 500MB 的临时存储 5 分钟,但之后您需要再运行 2 小时并且不会再接触那么多内存,请生成一个子进程来执行内存密集型工作。当子进程消失时,内存被释放。
这并不完全是微不足道和免费的,但它非常简单且便宜,这通常足以让交易变得值得。
首先,创建子进程的最简单方法是concurrent.futures(或者,对于 3.1 及更早版本,futuresPyPI 上的向后移植):
with concurrent.futures.ProcessPoolExecutor(max_workers=1) as executor:
result = executor.submit(func, *args, **kwargs).result()
如果您需要更多控制,请使用multiprocessing module.
费用为:
- 在某些平台上,尤其是 Windows,进程启动有点慢。我们这里谈论的是毫秒,而不是分钟,如果你让一个孩子完成 300 秒的工作,你甚至不会注意到它。但它不是免费的。
- 如果您使用的大量临时内存确实是large,这样做可能会导致您的主程序被换出。当然,从长远来看,您可以节省时间,因为如果该内存永远挂起,则必然会导致在某个时刻进行交换。但在某些用例中,这可能会将逐渐缓慢变成非常明显的一次性(和早期)延迟。
- 在进程之间发送大量数据可能会很慢。同样,如果您正在谈论发送超过 2K 的参数并返回 64K 的结果,您甚至不会注意到它,但如果您正在发送和接收大量数据,您将需要使用其他机制(一份文件,
mmap
ped 或其他方式;中的共享内存 APImultiprocessing
; etc.).
- 在进程之间发送大量数据意味着数据必须是可腌制的(或者,如果将它们保存在文件或共享内存中,
struct
- 能够或理想ctypes
-able).
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)