转载

如何手动释放Python的内存

在上篇博客中,提到了对一个脚本进行的多次优化。当时以为已经优化得差不多了,但是当测试人员测试时,我才发现,踩到了Python的一个大坑。

在上文的优化中,对每500个用户,会进行一些计算并记录结果在磁盘文件中。原本以为这么做,这些结果就在磁盘文件中了,而不会再继续占用内存;但实际上,Python的大坑就是Python不会自动清理这些内存。这是由其本身实现决定的。具体原因网上多有文章介绍,这里就不copy了。

本篇博客将贴一个笔者的实验脚本,用以说明Python确实存在这么一个不释放内存的现象,另外也提出一个解决方案,即:先del,再显式调用gc.collect(). 脚本和具体效果见下。


实验环境一:Win 7, Python 2.7

[python] view plain copy
  1. from time import sleep, time  
  2. import gc  
  3.   
  4. def mem(way=1):  
  5.     print time()  
  6.     for i in range(10000000):  
  7.         if way == 1:  
  8.             pass  
  9.         else:  # way 2, 3  
  10.             del i  
  11.               
  12.     print time()  
  13.     if way == 1 or way == 2:  
  14.         pass  
  15.     else:  # way 3  
  16.         gc.collect()  
  17.     print time()  
  18.           
  19. if __name__ == "__main__":  
  20.     print "Test way 1: just pass"  
  21.     mem(way=1)  
  22.     sleep(20)  
  23.     print "Test way 2: just del"  
  24.     mem(way=2)  
  25.     sleep(20)  
  26.     print "Test way 3: del, and then gc.collect()"  
  27.     mem(way=3)  
  28.     sleep(20)  
  29.       


运行结果如下:

[plain] view plain copy
  1. Test way 1: just pass  
  2. 1426688589.47  
  3. 1426688590.25  
  4. 1426688590.25  
  5. Test way 2: just del  
  6. 1426688610.25  
  7. 1426688611.05  
  8. 1426688611.05  
  9. Test way 3: del, and then gc.collect()  
  10. 1426688631.05  
  11. 1426688631.85  
  12. 1426688631.95  


对于way 1和way 2,结果是完全一样的,程序内存消耗峰值是326772KB,在sleep 20秒时,内存实时消耗是244820KB;

对于way 3,程序内存消耗峰值同上,但是sleep时内存实时消耗就只有6336KB了。


实验环境二: Ubuntu 14.10, Python 2.7.3


运行结果:

[plain] view plain copy
  1. Test way 1: just pass  
  2. 1426689577.46  
  3. 1426689579.41  
  4. 1426689579.41  
  5. Test way 2: just del  
  6. 1426689599.43  
  7. 1426689601.1  
  8. 1426689601.1  
  9. Test way 3: del, and then gc.collect()  
  10. 1426689621.12  
  11. 1426689622.8  
  12. 1426689623.11  

[plain] view plain copy
  1. ubuntu@my_machine:~$ ps -aux | grep test_mem  
  2. Warning: bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.html  
  3. ubuntu    9122 10.0  6.0 270916 245564 pts/1   S+   14:39   0:03 python test_mem.py  
  4. ubuntu    9134  0.0  0.0   8104   924 pts/2    S+   14:40   0:00 grep --color=auto test_mem  
  5. ubuntu@my_machine:~$ ps -aux | grep test_mem  
  6. Warning: bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.html  
  7. ubuntu    9122 10.0  6.0 270916 245564 pts/1   S+   14:39   0:03 python test_mem.py  
  8. ubuntu    9134  0.0  0.0   8104   924 pts/2    S+   14:40   0:00 grep --color=auto test_mem  
  9. ubuntu@my_machine:~$ ps -aux | grep test_mem  
  10. Warning: bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.html  
  11. ubuntu    9122 11.6  0.1  30956  5608 pts/1    S+   14:39   0:05 python test_mem.py  

结论:

以上说明,当调用del时,其实Python并不会真正release内存,而是将其继续放在其内存池中;只有在显式调用gc.collect()时,才会真正release内存。


进一步:

其实回到上一篇博客的脚本中,也让其引入gc.collect(),然后写个监控脚本监测内存消耗情况:

[plain] view plain copy
  1. while ((1)); do ps -aux | sort -n -k5,6 | grep my_script; free; sleep 5; done  

结果发现:内存并不会在每500个用户一组执行完后恢复,而是一直持续消耗到仅存约70MB时,gc才好像起作用。本环境中,机器使用的是Cloud instance,总内存2G,可用内存约为1G,本脚本内存常用消耗是900M - 1G。换句话说,对于这个脚本来说,gc并没有立即起作用,而是在系统可用内存从1 - 1.2G下降到只剩70M左右时,gc才开始发挥作用。这点确实比较奇怪,不知道和该脚本是在Thread中使用的gc.collect()是否有关,或者是gc发挥作用原本就不是可控的。笔者尚未做相关实验,可能在下篇博客中继续探讨。

但是,可以肯定的是,若不使用gc.collect(), 原脚本将会将系统内存耗尽而被杀死。这一点从syslog中可以明显看出。


原文路径:http://blog.csdn.net/nirendao/article/details/44426201/

文章最后发布于: 2017-01-04 21:58:26
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 编程工作室 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览