当我将文件加载到json中时,pythons的内存使用量会达到1.8 get左右,而我似乎无法释放这些内存。我整理了一个非常简单的测试用例:
with open("test_file.json", 'r') as f:
j = json.load(f)很抱歉,我不能提供一个示例json文件,我的测试文件有很多敏感信息,但是对于上下文,我正在处理一个大约240MB的文件。运行上述两行代码后,我使用了前面提到的1.8 in内存。如果我这样做了,del j内存使用率根本不会下降。如果我用gc.collect()跟在后面,它仍然不会掉下来。我甚至尝试卸载json模块并运行另一个gc.collect。
我正在尝试运行一些内存分析,但是heapy已经在100%的CPU上运行了大约一个小时,并且还没有产生任何输出。
有谁有什么想法吗?我也尝试过使用cjson而不是打包的json模块。cjson使用的内存减少了约30%,但在其他方面显示了完全相同的问题。
我在Ubuntu服务器11.10上运行Python 2.7.2。
我很乐意加载任何内存分析器,看看它是否比heapy做得更好,并提供您认为必要的任何诊断信息。我正在寻找一个大型的测试json文件,我可以提供给其他任何人来尝试它。
发布于 2012-06-16 04:53:09
我认为这两个链接解决了一些有趣的问题,这不一定是一个json问题,而仅仅是一个“大对象”问题,以及内存如何与python和操作系统一起工作。
请参阅Why doesn't Python release the memory when I delete a large object?,了解为什么从python释放的内存不一定会被操作系统反映出来:
如果您创建一个大对象并再次删除它,Python可能已经释放了内存,但涉及的内存分配器不一定将内存返回给操作系统,因此看起来Python进程使用的虚拟内存比它实际使用的要多得多。
关于让操作系统处理清理工作的running large object processes in a subprocess:
确保大量但临时的内存使用完成后将所有资源返回给系统的唯一真正可靠的方法是在子进程中使用内存,子进程执行耗用内存的工作,然后终止。在这种情况下,操作系统将完成它的工作,并且很乐意回收该子进程可能已经吞噬的所有资源。幸运的是,在Python.
的现代版本中,多处理模块使得这种操作(过去是相当痛苦的)并不是很糟糕。
https://stackoverflow.com/questions/11057712
复制相似问题