被骗了。。。谈python内存泄露

[张加林]

 刚刚学习python 的时候，看了不少文档，很多都有提到python的垃圾回收机制，当时以为从此和内存泄露说拜拜了，看来还是图样图僧破。

  前几天心血来潮，写了个扫描器，写完就想拿来试试，就从apnic下载了全球的ip分配表，写个脚本搞出中国的ip段，放到扫描器中扫描，然后睡觉去，准备早上起来看看结果。

  第二天起来，点亮屏幕的时候感觉特别慢，进去之后也感觉操作不对劲，立即top看了一下，扫描器占用了我60%的内存，当时心下一惊，wocao，遇到bug了。

  在网上摸了半天，终于找到源头：https://docs.python.org/2/reference/datamodel.html。

  在上面这个网页讲解__del__的地方谈到原来python也可能会出现内存泄露，第一种是出现在a->b , b->a的情况下，这个时候这两个对象的ref count永远不会变为0，python的垃圾回收器也就没法回收了。这个情况和操作系统的死锁似乎是一样的逻辑，都是由于在对资源（如果一个对象视为资源的话）的使用中出现了环，而对于环的检测非常困难，系统开销也非常大，所以即使是现在的操作系统也不做环的检测的，在出现死锁的情况的时候要么强制杀死一些进程，要么等到人工处理。

  我遇到的是第二种，（由于E文不溜，大概是这个意思吧）函数执行过程中，某个捕捉到的异常的对象的ref count，python不会自动把它变为0，而且函数的栈帧python也会保留着，用于traceback。我把我的扫描器拿去扫上亿的ip，每次对某个ip的扫描中出现异常的时候，执行这个函数的栈帧都会被保留下来，引发异常的对象也会被保留下来，这样经过一个晚上，我的内存就被慢慢吃掉了。这种情况的解决办法很简单，我对引发异常的情况不感兴趣，因为几乎都是timeout引发的，在上面那个网页给了很明确的解决办法：sys.exc_traceback=None即可，强制python扔掉traceback信息。

  第三种是在interactive模式下出现，我没看仔细，应该没有人能在interactive模式下慢慢玩到系统内存用完吧。。。

  that's all。

[张加林]

写掉了一点，对于第一种情况，原文也很清楚的写明了：The first situation can only be remedied by explicitly breaking the cycles。遇到第一种情况，您只能明确（手动）的打破环。

在 2015年2月7日星期六 UTC+8下午7:57:55，张加林写道：

[猪猪]

Python不成熟，做做小玩意还行，但7*24的ServerAPP万万不可用Python。‍

[Zoom.Quiet]

这话说的,
有多少项目/系统/工程 是 Py 运行的哪,,,
别不说 豆瓣 7*24 小时运行多少年了?!

2015-02-07 20:36 GMT+08:00 猪猪 <cspi...@qq.com>:
> Python不成熟，做做小玩意还行，但7*24的ServerAPP万万不可用Python。‍
>
> --
> 邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
> 规则: http://code.google.com/p/cpyug/wiki/PythonCn
> 详情: http://code.google.com/p/cpyug/wiki/CpyUg
> 严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
> ---
> 您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
> 要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。
> 要发帖到此群组，请发送电子邮件至pyth...@googlegroups.com。
> 要查看更多选项，请访问https://groups.google.com/d/optout。



--
Life's Pathetic, Let's Pythonic! 人生苦短, Python是岸!
俺: http://zoomquiet.io
授: http://creativecommons.org/licenses/by-sa/2.5/cn/
怒: 冗余不做,日子甭过!备份不做,十恶不赦!
KM keep growing environment culture which promoting organization be learnning!

[依云]

On Sat, Feb 07, 2015 at 04:02:54AM -0800, 张加林 wrote:
> 写掉了一点，对于第一种情况，原文也很清楚的写明了：The first situation can only be remedied by
> explicitly breaking the cycles。遇到第一种情况，您只能明确（手动）的打破环。

嗯，所以有了 weakref 这个东西。然后有人在文章里说，他会在读别人的代码的
时候情不自禁地去使用 weakref 来打破循环引用…………

其实你这种一夜就有明显症状的还好啦。我有个程序，得运行好几个月才能看到比
较明显的泄漏……这个样子基本没法调试，因为重现的周期太长太长了……重启是不错，
不过我有洁癖嘛。


--
Best regards,
lilydjwg

Linux Vim Python 我的博客:
http://lilydjwg.is-programmer.com/
--
A: Because it obfuscates the reading.
Q: Why is top posting so bad?

[zhaoweikid]

在 2015年2月7日 下午8:36，猪猪 <cspi...@qq.com>写道：

Python不成熟，做做小玩意还行，但7*24的ServerAPP万万不可用Python。‍

这个显然不是真的 

[猪猪]

首先我并不是贬低Python，我下到机器码，上到erlang，我都用。相比之下，我觉得Python非常优秀。我从前年开始让运维部门用Python，取得很好效果。

但是，我们也应该正视Python的缺点。Python太年轻，用户不多，很多方面的需求所对应的成熟解决方案也较少，因此，稳定性必然不如Java之流。所以我才建议，小玩意用Python写，很不错，但ServerAPP，还是不要给自己挖坑了。我知道目前有很多看起来不小的项目都用Python，但他们花了多少时间填坑，你们有了解过吗？

最后，还是那句话，用合适的工具，去做合适的事情。不要让狂热变成偏见。也许你是Python的铁粉，但客观才是你成长的动力。

[limodou]

感觉你对python的历史和应用了解太少。Java写不好一样有内存泄漏。哪个语言没坑呢？关键还是看自已的水平。合适的工具这句话说得不错，但是合适的工具也是因为人根据自已的情况挑出来的。同样一件事，不同的人选的所谓合适工具就可能不一样。

--

邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。
要发帖到此群组，请发送电子邮件至pyth...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--

I like python!
UliPad <<The Python Editor>>: http://code.google.com/p/ulipad/
UliWeb <<simple web framework>>: https://github.com/limodou/uliweb
My Blog: http://my.oschina.net/limodou

[limodou]

简单的办法是加个内存限制，超限重启。特别是对于周期性运行的python程序。象supervisor这样的工具有这样的插件，不行可以自已写，如使用psutils来检查内存使用情况。

--

邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。
要发帖到此群组，请发送电子邮件至pyth...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

[Zoom.Quiet]

"...不要让狂热变成偏见"
受教了...

不争论, 认真将事儿作出来, 不用证明什么,
关键是自个儿得在过程中爽了.

2015-02-07 21:48 GMT+08:00 猪猪 <cspi...@qq.com>:

> --
> 邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
> 规则: http://code.google.com/p/cpyug/wiki/PythonCn
> 详情: http://code.google.com/p/cpyug/wiki/CpyUg
> 严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
> ---
> 您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
> 要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。
> 要发帖到此群组，请发送电子邮件至pyth...@googlegroups.com。
> 要查看更多选项，请访问https://groups.google.com/d/optout。

[猪猪]

Python这么年轻，谈历史，有些言笑了。

Java写不好的确会存在内存泄露，Java也会有像这个主题一样的坑，但因为成熟，坑非常少，而且由于用户基数大，即使遇到坑了，通过搜索也能快速了解问题。

这些事情与水平无关。再有水平的人，时间也有限，不可能天天去碰坑去解决坑，更不可能有大量时间去精度每一份文档、源码来查明这些事情。为什么有些人收入上不去？就是这个原因，时间与产出比值太低。

不同的人，当然会有不同的合适的工具，但喜欢选择坑多的工具，喜欢把时间浪费在坑上，我觉得这公司的老板与HR应该好好反省下。‍

[Zoom.Quiet]

"...为什么有些人收入上不去？就是这个原因，时间与产出比值太低。"

俺生受了...
这的确是个正确的反推导,逻辑上正当,
只是俺总是感觉哪儿有不对的.
大家怎么看?

只是, 这楼偏的哪, 很经典.

> --
> 邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
> 规则: http://code.google.com/p/cpyug/wiki/PythonCn
> 详情: http://code.google.com/p/cpyug/wiki/CpyUg
> 严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
> ---
> 您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
> 要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。
> 要发帖到此群组，请发送电子邮件至pyth...@googlegroups.com。
> 要查看更多选项，请访问https://groups.google.com/d/optout。



--

[Tian]

java比python还年轻。。。

2015-02-07 21:48 GMT+08:00 猪猪 <cspi...@qq.com>:

--

[风间星魂]

python年轻？别搞笑了。

python历史比java老。。。

1989年的圣诞节期间，吉多·范罗苏姆 开发出python。

任职于太阳微系统的詹姆斯·高斯林等人于1990年代初开发Java语言的雏形，最初被命名为Oak，目标设置在家用电器等小型系统的程序语言，应用在电视机、电话、闹钟、烤面包机等家用电器的控制和通信。由于这些智能化家电的市场需求没有预期的高，Sun公司放弃了该项计划。随着1990年代互联网的发展，Sun公司看见Oak在互联网上应用的前景，于是改造了Oak，于1995年5月以Java的名称正式发布。Java伴随着互联网的迅猛发展而发展，逐渐成为重要的网络编程语言。

--

邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。
要发帖到此群组，请发送电子邮件至pyth...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--

我的blog: http://blog-fengjian.rhcloud.com/

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2

mQENBFTDNCYBCADiGu5VTBsFfU6r4wSbJCbxeGaArq5lP+VAMB0KZR7zPLVgvkbO
AQXrknHvTNyIcIgQEEk0KmQzpWXat1f9+RyynHYjuk6vzukSqxDePjR4O3ddtiTS
14+q6mTexIVmtNcnRnoZDrYSortbDe+rkGuTG/MTur61E+tF7m447eJnPxCsMdS6
2I/R8WWag8twhX+SJ+dx5WEBueb1nKUHMTjuqLlLrCAJt/MxRl8hdpFTEVai4+RU
N3WiJC1tpJGDVQYkeut7HbduWadqLfsKgWCsITxiNNHJdAMb4buv7JCFKtHTqB4/
yuY603rz2RyU59EXl5aKCGCC7RBmoylFetg9ABEBAAG0K2ZlbmdqaWFueGluZ2h1
biA8ZmVuZ2ppYW54aW5naHVuQGdtYWlsLmNvbT6JATkEEwECACMFAlTDNCYCGwMH
CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCNyBXBft+OpyLoB/9PlL1w/kzf
b1sFb370lXIsyfTbX5TTM+kxQrY1LGZY/LXy+NPkmcAsUBSuZJspFFibdNXl6CJp
+FHO1zXtymCXTl5QV4YgKdS5LHim2Y7l4A1tk7kwB84XaxcOXZ5yxPVTb+oKybPg
hirhWEr54YRfFh8O1SkSJiKA/4PHmhsXBfPk0aEKCBk9xEwEMHnkv19p/7ttRknG
G8KJEQh3LnB28IW6yb/atXtjLHerQsqFxX5IE5ep9mCgQj/RjObzV7fWbCwyiIIC
vGr84ufonHWYSF71oDdbcT00ccYXiQLMwcINssOCoQpMMkWIYfkxi+0nQkIuNeWf
/WFfAtIzUwk3uQENBFTDNCYBCADP0C96qgABqZRtXfStW7JiZZ+vgiCub1QTQ9jS
AWh4ztDtVsXXWLWu4vTTDhtt4mn9OEbsCIAFpcro+Y9jjrjj26NhHCFVmFJMYYNi
Jtnk5tiJ9iGdJQ3LidVStjxz8ksqoRhEaDARpNgwgTXQXVwtGiuuINS/QKBwwI9G
z5CFX799P7ZmeXwdEe+XpY0e+4Uru+NLmeLzjpylg4ViPg04IlyLui+NJCsKn7I0
uSTIeJER6a5gFLTSqGjMc2p4EA2Y51lJ82//bnH9jILNjy6KUFb1DwwNTwFp/h8j
Q3Zl3aybTeq7LesV79XvegY3rGsu/x8q8zSUV4+YMfZH6DOJABEBAAGJAR8EGAEC
AAkFAlTDNCYCGwwACgkQjcgVwX7fjqd+AggAvC2/6CXPX3ALOpBy0twTV8MS5fkW
tqjcxB3wyFdPhQkrc5VX+Kfbag7NuNEHH2MBFcbVlN21mpbYyZOKeTCvv0iW2Flm
WArUkXFe04cojGWpzVYjJ+T+14Ym1Ns2MpVfgnYf7TOTJZtGI3YufovlRRxSL2Wi
CK57LDjMZR7AlI9k3yjtdNQPYz2Degmr3EyFDVfB/o6E+vCbUOcSz3LOQTJhSXWw
aq0VjKrFh5OaO/y7K3R3QZ1Tgdh4AGJes92nqNRpj0NVx8Q4cvJK3P/MmOgaPLlM
SLl5UH+siMkNw4WdgnKWHL2l90Q3/ENfvpLGK0l8sD9+uYI986e9RcHwUw==
=BpLT
-----END PGP PUBLIC KEY BLOCK-----

[Doyle]

查了一下维基百科……

python在1989年开始被实现（具体发布不知

python2在2000年10月发布

java 算上其前身oak，自90年12月被立项

94年由oak 改名java，95年java正式发布

2000年发布了jdk 1.3和1.4

嗯……算上oak……也还是比python 年轻一岁啊……

您收到此邮件是因为您订阅了 Google 网上论坛的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。

要向此群组发帖，请发送电子邮件至 pyth...@googlegroups.com。
要查看更多选项，请访问 https://groups.google.com/d/optout。

[张加林]

在我去点开维基百科的一瞬间，我就想到，论坛里绝对有人也正在wiki python和java，回来一看，果然。

选择python的人多具有某些相同的特质，比如，遇到一个问题，想到的绝对是马上解决它，首先google一下，嗯，是这样的。我们就是这样的人。我有很多想说的，但是我觉得大家都能感受到，就不说了。

楼歪的很严重。

任何语言本质上都逃不过数学规律，任你发展到人类语言编程的地步，二叉树还是二叉树，最大子序列和的时间复杂度永远是O(n)，该死锁还是死锁。

编程语言的选择完全是个性使然或生活所迫。

在 2015年2月7日星期六 UTC+8下午7:57:55，张加林写道：

 刚刚学习python 的时候，看了不少文档，很多都有提到python的垃圾回收机制，当时以为从此和内存泄露说拜拜了，看来还是图样图僧破。

[张加林]

可重入还不会对最终结果造成影响的，加内存限制，超限重启是个相当简单便捷的方法，不过如果程序保存退出点的进度相当麻烦的话还是很蛋疼的。最近在写一个爬虫就相当蛋疼，一直没有条件可以让程序7x24小时的跑，就做一个进度保存，下次继续，手头上一直事情又多，到现在都还没去解决。

在 2015年2月7日星期六 UTC+8下午10:01:21，limodou写道：

简单的办法是加个内存限制，超限重启。特别是对于周期性运行的python程序。象supervisor这样的工具有这样的插件，不行可以自已写，如使用psutils来检查内存使用情况。

2015-02-07 19:57 GMT+08:00 张加林 <caini...@gmail.com>:

 刚刚学习python 的时候，看了不少文档，很多都有提到python的垃圾回收机制，当时以为从此和内存泄露说拜拜了，看来还是图样图僧破。

  前几天心血来潮，写了个扫描器，写完就想拿来试试，就从apnic下载了全球的ip分配表，写个脚本搞出中国的ip段，放到扫描器中扫描，然后睡觉去，准备早上起来看看结果。

  第二天起来，点亮屏幕的时候感觉特别慢，进去之后也感觉操作不对劲，立即top看了一下，扫描器占用了我60%的内存，当时心下一惊，wocao，遇到bug了。

  在网上摸了半天，终于找到源头：https://docs.python.org/2/reference/datamodel.html。

  在上面这个网页讲解__del__的地方谈到原来python也可能会出现内存泄露，第一种是出现在a->b , b->a的情况下，这个时候这两个对象的ref count永远不会变为0，python的垃圾回收器也就没法回收了。这个情况和操作系统的死锁似乎是一样的逻辑，都是由于在对资源（如果一个对象视为资源的话）的使用中出现了环，而对于环的检测非常困难，系统开销也非常大，所以即使是现在的操作系统也不做环的检测的，在出现死锁的情况的时候要么强制杀死一些进程，要么等到人工处理。

  我遇到的是第二种，（由于E文不溜，大概是这个意思吧）函数执行过程中，某个捕捉到的异常的对象的ref count，python不会自动把它变为0，而且函数的栈帧python也会保留着，用于traceback。我把我的扫描器拿去扫上亿的ip，每次对某个ip的扫描中出现异常的时候，执行这个函数的栈帧都会被保留下来，引发异常的对象也会被保留下来，这样经过一个晚上，我的内存就被慢慢吃掉了。这种情况的解决办法很简单，我对引发异常的情况不感兴趣，因为几乎都是timeout引发的，在上面那个网页给了很明确的解决办法：sys.exc_traceback=None即可，强制python扔掉traceback信息。

  第三种是在interactive模式下出现，我没看仔细，应该没有人能在interactive模式下慢慢玩到系统内存用完吧。。。

  that's all。

--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。

要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。

要发帖到此群组，请发送电子邮件至pyth...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

[Zoom.Quiet]

不要在意这些细节,
谁年轻,谁老, 从来不是靠 commit log 决定的,
好比刘晓庆?

嗯嗯嗯, 合适与否,一向的成功后的判定,
在此之前, 完全看我们自个儿相信什么了.

[Glowin]

邮件列表每次讨论最激烈的就是语言之争了:-(

最好的语言是PHP啊亲们

On 2015年2月7日 周六 at 下午10:59 Zoom.Quiet <zoom....@gmail.com> wrote:

不要在意这些细节,
谁年轻,谁老, 从来不是靠 commit log 决定的,
好比刘晓庆?

嗯嗯嗯, 合适与否,一向的成功后的判定,
在此之前, 完全看我们自个儿相信什么了.




2015-02-07 22:31 GMT+08:00 Tian <ask...@gmail.com>:
> java比python还年轻。。。
>
> 2015-02-07 21:48 GMT+08:00 猪猪 <cspi...@qq.com>:
>>
>>
>> 首先我并不是贬低Python，我下到机器码，上到erlang，我都用。相比之下，我觉得Python非常优秀。我从前年开始让运维部门用Python，取得很好效果。
>>
>>
>> 但是，我们也应该正视Python的缺点。Python太年轻，用户不多，很多方面的需求所对应的成熟解决方案也较少，因此，稳定性必然不如Java之流。所以我才建议，小玩意用Python写，很不错，但ServerAPP，还是不要给自己挖坑了。我知道目前有很多看起来不小的项目都用Python，但他们花了多少时间填坑，你们有了解过吗？
>>
>> 最后，还是那句话，用合适的工具，去做合适的事情。不要让狂热变成偏见。也许你是Python的铁粉，但客观才是你成长的动力。
>>
>> --
>> 邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
>> 规则: http://code.google.com/p/cpyug/wiki/PythonCn
>> 详情: http://code.google.com/p/cpyug/wiki/CpyUg
>> 严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
>> ---
>> 您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。

>> 要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。
>> 要发帖到此群组，请发送电子邮件至python-cn@googlegroups.com。

>> 要查看更多选项，请访问https://groups.google.com/d/optout。
>
>
> --
> 邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
> 规则: http://code.google.com/p/cpyug/wiki/PythonCn
> 详情: http://code.google.com/p/cpyug/wiki/CpyUg
> 严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
> ---
> 您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。

> 要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。
> 要发帖到此群组，请发送电子邮件至python-cn@googlegroups.com。

> 要查看更多选项，请访问https://groups.google.com/d/optout。



--
Life's Pathetic, Let's Pythonic! 人生苦短, Python是岸!
俺: http://zoomquiet.io
授: http://creativecommons.org/licenses/by-sa/2.5/cn/
怒: 冗余不做,日子甭过!备份不做,十恶不赦!
KM keep growing environment culture which promoting organization be learnning!

--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---

您收到此邮件是因为您订阅了 Google 网上论坛的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。

[bosby j]

不好用，偷偷换掉即可，非得说谁好谁不好。谁的老婆好？别人的老婆永远好。

PHP是最好的语言！

[Hunter Chen]

此言差矣。你太武断了

2015-02-07 20:36 GMT+08:00 猪猪 <cspi...@qq.com>:

Python不成熟，做做小玩意还行，但7*24的ServerAPP万万不可用Python。‍

--

[Catstyle Lee]

萝卜青菜，各有所爱，我用着python最爽就行了
嗯，PHP是世界上最好的语言，逃...

>>> >> 要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。
>>> >> 要发帖到此群组，请发送电子邮件至pyth...@googlegroups.com。
>>> >> 要查看更多选项，请访问https://groups.google.com/d/optout。
>>> >
>>> >
>>> > --
>>> > 邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
>>> > 规则: http://code.google.com/p/cpyug/wiki/PythonCn
>>> > 详情: http://code.google.com/p/cpyug/wiki/CpyUg
>>> > 严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
>>> > ---
>>> > 您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
>>> > 要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。
>>> > 要发帖到此群组，请发送电子邮件至pyth...@googlegroups.com。
>>> > 要查看更多选项，请访问https://groups.google.com/d/optout。
>>>
>>>
>>>

>>> --
>>> Life's Pathetic, Let's Pythonic! 人生苦短, Python是岸!
>>> 俺: http://zoomquiet.io
>>> 授: http://creativecommons.org/licenses/by-sa/2.5/cn/
>>> 怒: 冗余不做,日子甭过!备份不做,十恶不赦!
>>> KM keep growing environment culture which promoting organization be
>>> learnning!
>>>
>>> --
>>> 邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
>>> 规则: http://code.google.com/p/cpyug/wiki/PythonCn
>>> 详情: http://code.google.com/p/cpyug/wiki/CpyUg
>>> 严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
>>> ---
>>> 您收到此邮件是因为您订阅了 Google 网上论坛的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。

>>> 要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。

>>> 要向此群组发帖，请发送电子邮件至 pyth...@googlegroups.com。
>>> 要查看更多选项，请访问 https://groups.google.com/d/optout。
>>>
>> --
>> 邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
>> 规则: http://code.google.com/p/cpyug/wiki/PythonCn
>> 详情: http://code.google.com/p/cpyug/wiki/CpyUg
>> 严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
>> ---
>> 您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
>> 要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。
>> 要发帖到此群组，请发送电子邮件至pyth...@googlegroups.com。
>> 要查看更多选项，请访问https://groups.google.com/d/optout。
>>
>

> --
> 邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
> 规则: http://code.google.com/p/cpyug/wiki/PythonCn
> 详情: http://code.google.com/p/cpyug/wiki/CpyUg
> 严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
> ---
> 您收到此邮件是因为您订阅了 Google 网上论坛的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。

> 要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。

> 要向此群组发帖，请发送电子邮件至 pyth...@googlegroups.com。
> 要查看更多选项，请访问 https://groups.google.com/d/optout。
>


--

BR,
/Catstyle_Lee

[yegle]

就内存管理这块，说Java没坑，你让那些分析研究GC机制的架构师脸放哪去？

>>> >> 要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。
>>> >> 要发帖到此群组，请发送电子邮件至python-cn@googlegroups.com。

>>> >> 要查看更多选项，请访问https://groups.google.com/d/optout。
>>> >
>>> >
>>> > --
>>> > 邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
>>> > 规则: http://code.google.com/p/cpyug/wiki/PythonCn
>>> > 详情: http://code.google.com/p/cpyug/wiki/CpyUg
>>> > 严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
>>> > ---
>>> > 您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。

>>> > 要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。
>>> > 要发帖到此群组，请发送电子邮件至python-cn@googlegroups.com。

>>> > 要查看更多选项，请访问https://groups.google.com/d/optout。
>>>
>>>
>>>
>>> --
>>> Life's Pathetic, Let's Pythonic! 人生苦短, Python是岸!
>>> 俺: http://zoomquiet.io
>>> 授: http://creativecommons.org/licenses/by-sa/2.5/cn/
>>> 怒: 冗余不做,日子甭过!备份不做,十恶不赦!
>>> KM keep growing environment culture which promoting organization be
>>> learnning!
>>>
>>> --
>>> 邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
>>> 规则: http://code.google.com/p/cpyug/wiki/PythonCn
>>> 详情: http://code.google.com/p/cpyug/wiki/CpyUg
>>> 严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
>>> ---
>>> 您收到此邮件是因为您订阅了 Google 网上论坛的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。

>>> 要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。

>>> 要向此群组发帖，请发送电子邮件至 pyth...@googlegroups.com。
>>> 要查看更多选项，请访问 https://groups.google.com/d/optout。
>>>
>>  --
>> 邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
>> 规则: http://code.google.com/p/cpyug/wiki/PythonCn
>> 详情: http://code.google.com/p/cpyug/wiki/CpyUg
>> 严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
>> ---
>> 您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。

>> 要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。
>> 要发帖到此群组，请发送电子邮件至python-cn@googlegroups.com。

>> 要查看更多选项，请访问https://groups.google.com/d/optout。
>>
>
> --
> 邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
> 规则: http://code.google.com/p/cpyug/wiki/PythonCn
> 详情: http://code.google.com/p/cpyug/wiki/CpyUg
> 严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
> ---
> 您收到此邮件是因为您订阅了 Google 网上论坛的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。

> 要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。

> 要向此群组发帖，请发送电子邮件至 pyth...@googlegroups.com。
> 要查看更多选项，请访问 https://groups.google.com/d/optout。
>


--
BR,
/Catstyle_Lee

--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了 Google 网上论坛的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。

要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。

[limodou]

应该象http一样考虑无状态，比如把要爬的内容放在数据库中，添加处理标志。这样应该可以随时重启吧。

要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。

要发帖到此群组，请发送电子邮件至pyth...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

[limodou]

对了放在redis之类的nosql也很方便。

[HYRY]

Python的垃圾回收缺省配置就能回收环。在Python 3.4之前如果定义了__del__的话，环回收可能会出问题：

Circular references which are garbage are detected when the option cycle detector is enabled (it’s on by default), but can only be cleaned up if there are no Python-level __del__() methods involved.

不过这个问题已经在Python 3.4中解决了。

https://docs.python.org/3.4/whatsnew/3.4.html#pep-442-safe-object-finalization

2015年2月7日土曜日 20時57分55秒 UTC+9 张加林:

[HYRY]

你通过sys.exc_traceback=None解决了你的程序的内存问题了吗？
我读文档的意思是说，这三种情况都会出现环，但是Python可以回收环。你自定义了__del__么？你用的Python是什么版本？

你可以隔一段时间执行一次gc.collect(), 查看一下gc.garbage是否为空。如果即使这样仍然内存不断增长，
多半是程序中有某个引用导致无法释放对象。

就我遇到的绝大多数内存问题都是自己程序的问题。可以用objgraph之类的调试试试看：

http://chase-seibert.github.io/blog/2013/08/03/diagnosing-memory-leaks-python.html

[孑影]

我是来歪楼的,
python 内存这一块,看了看,感觉怪怪的,说不上不好,说不上差,想想一切皆对象,,一个server 7*24 那得多少次malloc呢,
虽然有缓存但是我用perf 测了一下 命中率不是很高 括弧 有可能是我代码写得差 括弧
这样看还真不利于长期7*24的跑,目前来看还真的得定期的重启才能解决内存这一块的问题
#风起看云涌，叶落品人生#

[张加林]

我爬的百度贴吧，爬过的内容的标记倒是挺简单的，因为贴吧每个帖子的url都是标准的tieba.baidu.com/p/{pid}&pn={page_number}，只要记录pid和page_number就可以标记了。考虑到爬一个页面处理一个页面会很浪费，为了同时爬页面同时处理页面，就做了几个队列，一些线程专门爬，爬下来放到队列，一些线程从队列里取出数据进行处理。要重启时恢复队列得用pickle，但是还没用过pickle就没动手去解决。

在 2015年2月8日星期日 UTC+8上午9:51:10，limodou写道：

[张加林]

我用的2.7.9。

试过objgraph，等了一个小时没见到数量变化多少，就放弃了。

昨天晚上又跑了一晚上，早上起来看内存占用仍有增长，开始十几分钟后在0.3%左右，早上起来到0.6%，应该还是有地方在泄露，不过我算了一下按照这个泄露速度，等扫完全部IP段应该占用在25%左右，就没去纠结了。

但是，但是，家里网络的上行实在慢，算下来要跑三个月才扫的完：（

在 2015年2月8日星期日 UTC+8下午12:16:52，HYRY写道：

[shaung]

还有一种情况是 heap fragmentation，非常之噩梦
http://blog.ez2learn.com/2010/04/22/memory-efficient-python-with-bytearray/

--

邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。

要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。

要发帖到此群组，请发送电子邮件至pyth...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--

Cheers,
Shaun

[依云]

On Sat, Feb 07, 2015 at 08:03:32PM -0800, HYRY wrote:
> Python的垃圾回收缺省配置就能回收环。在Python 3.4之前如果定义了__del__的话，环回收可能会出问题：
>
> Circular references which are garbage are detected when the option cycle
> detector is enabled (it’s on by default), but can only be cleaned up if
> there are no Python-level __del__()

> <https://docs.python.org/2/reference/datamodel.html#object.__del__> methods

> involved.
>
> 不过这个问题已经在Python 3.4中解决了。
>
> https://docs.python.org/3.4/whatsnew/3.4.html#pep-442-safe-object-finalization

这个 PEP 所解决的问题我没有遇到过，但是它给我带来了问题。文档说「This
avoids a whole class of interpreter-shutdown-time errors, usually
involving __del__ methods, that have plagued Python since the cyclic GC
was first introduced.」可本来在 3.4 之前（当然是 2.7 之后）里在解释器关
闭时能够正确处理的 __del__ 方法，在 3.4 里反而有问题了 QAQ

代码在这里：
https://github.com/lilydjwg/winterpy/blob/master/pylib/serializer.py


--
Best regards,
lilydjwg

Linux Vim Python 我的博客:
http://lilydjwg.is-programmer.com/
--
A: Because it obfuscates the reading.
Q: Why is top posting so bad?

[HYRY]

你是说要在解释器退出之前调用__del__吗？

根据文档：

https://docs.python.org/2/reference/datamodel.html#object.__del__

It is not guaranteed that __del__() methods are called for objects that still exist when the interpreter exits.

Python没有保证在解释器退出以前一定调用__del__()，因此即使2.7能正常工作也是侥幸而已。

在 2015年2月8日星期日 UTC+9下午3:50:35，依云写道：

[严超]

Python有bug，但是不妨碍python作为7*24的ServerAPP，只要规避bug，python完全能在生产环境中运行。

Best Regards！

Chao Yan
--------------
My twitter：Andy Yan @yanchao727
My Weibo：http://weibo.com/herewearenow
--------------

--

邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---

[依云]

On Sat, Feb 07, 2015 at 11:23:20PM -0800, HYRY wrote:
> 你是说要在解释器退出之前调用__del__吗？
>
> 根据文档：
>
> https://docs.python.org/2/reference/datamodel.html#object.__del__
>
> It is not guaranteed that __del__()

> <https://docs.python.org/2/reference/datamodel.html#object.__del__> methods

> are called for objects that still exist when the interpreter exits.
>
> Python没有保证在解释器退出以前一定调用__del__()，因此即使2.7能正常工作也是侥幸而已。

不是的，在 2.7 里是不正常的。目前 3.4 里的结果是调用了，但是它所需要的全
局对象变成 None 了。


--
Best regards,
lilydjwg

[Gelin Yan]

__del__我写的代码从来没用过。

--

[牛魔王]

看到@猪猪的言论，我不由得想起，昨天晚上，我神装军团长买活后守高地，队友水人很好心的提示我“你买活的，打小兵是没钱的”。我看着他水人努力的出了把虚灵刀，也在努力守高地，也就不想说啥了。

[Chunlin Zhang]

内存碎片这种是不是所有语言都类似?还是python比较严重?

在 2015年2月8日星期日 UTC+8下午2:06:35，shaung写道：

要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。

要发帖到此群组，请发送电子邮件至pyth...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--

Cheers,
Shaun

[风间星魂]

可以自己手动分配内存的内存碎片能解决。比如C家族。。。。

要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。

要发帖到此群组，请发送电子邮件至pyth...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--

[Chunlin Zhang]

2015-02-09 9:48 GMT+08:00 风间星魂 <fengjia...@gmail.com>:

可以自己手动分配内存的内存碎片能解决。比如C家族。。。。

C也是一样阿,如果常驻内存跑久了一样有内存碎片阿, 什么叫做"自己手动分配内存的内存碎片"?

[Zhenbo Li]

在 2015年2月9日 上午10:12，Chunlin Zhang <zhangc...@gmail.com> 写道：
>
>
> 2015-02-09 9:48 GMT+08:00 风间星魂 <fengjia...@gmail.com>:
>>
>> 可以自己手动分配内存的内存碎片能解决。比如C家族。。。。
>
> C也是一样阿,如果常驻内存跑久了一样有内存碎片阿, 什么叫做"自己手动分配内存的内存碎片"?

你可以一次性申请一段大内存，然后自己维护一个内存池

--
Have a nice day!
Zhenbo Li

[风间星魂]

可以自己手动分配内存的语言，内存碎片问题可以解决。
自己写内存池，或者直接用brk/sbrk之类的系统调用重写内存分配函数。

在 2015年2月9日 上午10:12，Chunlin Zhang <zhangc...@gmail.com>写道：

[Mengyang Li]

在 2015年2月7日 上午6:11，猪猪 <cspi...@qq.com>写道：

Python这么年轻，谈历史，有些言笑了。

Python:

Appeared in	1991; 24 years ago

Java:

Appeared in	1995; 20 years ago[1]

来源:

http://en.wikipedia.org/wiki/Python_%28programming_language)
http://en.wikipedia.org/wiki/Java_(programming_language)

--

Best regards,

ᶘ ᵒᴥᵒᶅ

Mengyang Li

[Mengyang Li]

在 2015年2月7日 上午3:57，张加林 <caini...@gmail.com>写道：

写个脚本搞出中国的ip段，放到扫描器中扫描

感觉要是想写出内存泄露也真不容易。

[风间星魂]

循环引用大部分都是设计问题。。。。。。

--

[Chunlin Zhang]

2015-02-09 10:14 GMT+08:00 Zhenbo Li <liti...@gmail.com>:

在 2015年2月9日 上午10:12，Chunlin Zhang <zhangc...@gmail.com> 写道：
>
>
> 2015-02-09 9:48 GMT+08:00 风间星魂 <fengjia...@gmail.com>:
>>
>> 可以自己手动分配内存的内存碎片能解决。比如C家族。。。。
>
> C也是一样阿,如果常驻内存跑久了一样有内存碎片阿, 什么叫做"自己手动分配内存的内存碎片"?


你可以一次性申请一段大内存，然后自己维护一个内存池

这不是一样的吗?这个内存池跑久了一样有内存碎片的问题 

--
Have a nice day!
Zhenbo Li

[风间星魂]

。。。。先google一下“内存碎片”和malloc函数的实现吧。。

---

[Chunlin Zhang]

2015-02-09 10:36 GMT+08:00 风间星魂 <fengjia...@gmail.com>:

。。。。先google一下“内存碎片”和malloc函数的实现吧。。

我以前是搞嵌入式的,自己实现类似于malloc函数的C环境也是用过的,这部分我觉得不用和我科普了

[牛魔王]

java也有循环引用的问题，吐槽python这个，根本就没有抓住python的痛点。而且根据过去6年写python项目的经验，包括游戏脚本，web项目，以及各种工具，python确实有BUG，但是真正引起宕机的BUG，从来就是自己水平菜引起的，根本和python没啥关系，喷python不稳定的，明显“人笨怪刀钝”，也和现在大环境有关了，一个团队的失败，大部分人都是觉得有猪队友拖累自己，从来不从自己身上找原因。

---

[Chunlin Zhang]

是不是大家碰到这种问题比较多是用定时重启的方式来解决呢?

我之前碰到过一个uliweb写的web服务用uwsgi部署有问题怎么配都搞不定,改用gevent方式部署以后能工作,但是后来又发现gevent方式的部署运行起来有文件句柄的泄露问题,找了半天也找不到原因,后来先用每天晚上重启的方式先解决了

现在想起来不知道跟楼主的这个原因有没有关系

在 2015年2月7日星期六 UTC+8下午10:01:21，limodou写道：

简单的办法是加个内存限制，超限重启。特别是对于周期性运行的python程序。象supervisor这样的工具有这样的插件，不行可以自已写，如使用psutils来检查内存使用情况。

2015-02-07 19:57 GMT+08:00 张加林 <caini...@gmail.com>:

[小熊]

楼主的嘈点是python没有把内存还给系统.  内存缓慢增长并不一定是内存泄漏. 这个和内存回收机制有关系. 

不太了解回收机制, 直接导入gc模块, 手动gc.collect() 回收可能对楼主有帮助.

[Shell Xu]

我先打个脸，问个常识问题。

python和java哪个更年轻？

在 2015年2月7日 下午9:48，猪猪 <cspi...@qq.com>写道：

首先我并不是贬低Python，我下到机器码，上到erlang，我都用。相比之下，我觉得Python非常优秀。我从前年开始让运维部门用Python，取得很好效果。

但是，我们也应该正视Python的缺点。Python太年轻，用户不多，很多方面的需求所对应的成熟解决方案也较少，因此，稳定性必然不如Java之流。所以我才建议，小玩意用Python写，很不错，但ServerAPP，还是不要给自己挖坑了。我知道目前有很多看起来不小的项目都用Python，但他们花了多少时间填坑，你们有了解过吗？

最后，还是那句话，用合适的工具，去做合适的事情。不要让狂热变成偏见。也许你是Python的铁粉，但客观才是你成长的动力。

--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。
要发帖到此群组，请发送电子邮件至pyth...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--

彼節者有間，而刀刃者無厚；以無厚入有間，恢恢乎其於游刃必有餘地矣。
blog: http://shell909090.org/blog/

twitter: @shell909090
about.me: http://about.me/shell909090

[Gelin Yan]

关于内存碎片的部分，可以参考一下陈硕的文章。

http://blog.csdn.net/solstice/article/details/6527585

要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。

[小熊]

python 代码很少遇到内存泄漏的问题, 除了有个项目引入lucene 导致内存无法释放, 时间久了内存会泄漏.  

解决方案, 搜索换成staicsearch, 通过rest api 调用,

[Yu Lao 劳小鱼]

“人笨怪刀钝”

默默点赞……

捂脸然后火速爬开……

要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。

[Leo Xu]

说实话虽然我也时不时的使用循环引用，但是还从来没遇到过需要管理内存的情况，所以没研究过。

丢个问题：
最近做了个东西，建了个Graph来模拟SQL数据库的关系图，其中Node和Link的对象自然涉及到大量的相互引用，但是所有的引用都在Graph内部，请问这种情况，假如直接删除整个Graph，其中的Node和Link相当于就成了一片相互有联系的孤岛群，那这种情况下这些Node和Link会被自动回收吗？

要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。

[Jun Huang]

你们还是不要歪楼了, 回到楼主的正题上来吧.

楼主引用的原文是来源于这一段的, 我简单分一下段落, 地址:
https://docs.python.org/2/reference/datamodel.html#object.__del__

Note:

del x doesn’t directly call x.__del__() — the former decrements the
reference count for x by one, and the latter is only called when x‘s
reference count reaches zero.

Some common situations that may prevent the reference count of an
object from going to zero include:

* circular references between objects (e.g., a doubly-linked list or a
tree data structure with parent and child pointers);
* a reference to the object on the stack frame of a function that
caught an exception (the traceback stored in sys.exc_traceback keeps
the stack frame alive);
* or a reference to the object on the stack frame that raised an
unhandled exception in interactive mode (the traceback stored in
sys.last_traceback keeps the stack frame alive).

The first situation can only be remedied by explicitly breaking the cycles;

the latter two situations can be resolved by storing None in
sys.exc_traceback or sys.last_traceback.

Circular references which are garbage are detected when the option
cycle detector is enabled (it’s on by default), but can only be

cleaned up if there are no Python-level __del__() methods involved.

Refer to the documentation for the gc module for more information
about how__del__() methods are handled by the cycle detector,
particularly the description of the garbage value.

Python 的内存管理是有两套机制组成的: 引用计数 + gc.

在没有循环引用的情况下, 对象的内存回收是依靠引用计数完成的, 在引用计数变为0时, 如果有 __del__, 则 __del__
被调用. 注意, 不管有没有 __del__, 内存最后都会被回收.

如果有对象处于循环引用中, 引用计数就解决不了问题了, 这时是靠 gc 来检测的. Python 的 gc 只能解决循环引用中的对象均不包含
__del__ 的情况. 满足这种情况时, 内存也会在适当的时候被回收掉. 不过, 如果有对象有 __del__, 那这整个对象链就变成
uncollectable 的了, 无法被回收. 这个是合理的, 文档里面有解释, 地址是在
https://docs.python.org/2/library/gc.html#gc.garbage . 为了避免这种问题,
在设计之初就要使用 依云 说的 weakref 来避免. 这个问题在 Java 里面也是一样的解决方案. 其他的具有 GC
的语言应该都是类似的设计.

楼主怀疑自己的问题是第二种, 因为 exception 的 traceback 持有了 stack frame, 里面有对对象的的引用.
不过, 真要造成内存"泄露", 靠 sys.ex c_traceback 有点困难:

* 这个变量只会保存最近一次异常的情况, 下一次异常来了, 这个变量就被换掉了, 原来的对象也被释放了. 对于这个对象的释放来讲,
释放时机与你直接强制设置变量为 None 而言仅仅是一早一晚的区别
* 这个变量是全局的, 还不是线程绑定的. 我猜测, 楼主的程序是多线程的, 如果真想清空当前线程的异常 traceback, 应该使用
sys.exc_clear() .

我最终仍然是觉得, 楼主的代码仍然应该是自己持有了不该持有的对象引用, 才导致内存使用量一直上升.

--
一堆南极熊聚在一起做计算, 大家都不累. 恩.
Blog : http://leemars-blog.heroku.com
MSN & Gtalk : leemars at gmail.com

2015-02-07 19:57 GMT+08:00 张加林 <caini...@gmail.com>:

> 刚刚学习python 的时候，看了不少文档，很多都有提到python的垃圾回收机制，当时以为从此和内存泄露说拜拜了，看来还是图样图僧破。
>
> 前几天心血来潮，写了个扫描器，写完就想拿来试试，就从apnic下载了全球的ip分配表，写个脚本搞出中国的ip段，放到扫描器中扫描，然后睡觉去，准备早上起来看看结果。
>
> 第二天起来，点亮屏幕的时候感觉特别慢，进去之后也感觉操作不对劲，立即top看了一下，扫描器占用了我60%的内存，当时心下一惊，wocao，遇到bug了。
> 在网上摸了半天，终于找到源头：https://docs.python.org/2/reference/datamodel.html。
> 在上面这个网页讲解__del__的地方谈到原来python也可能会出现内存泄露，第一种是出现在a->b ,
> b->a的情况下，这个时候这两个对象的ref
> count永远不会变为0，python的垃圾回收器也就没法回收了。这个情况和操作系统的死锁似乎是一样的逻辑，都是由于在对资源（如果一个对象视为资源的话）的使用中出现了环，而对于环的检测非常困难，系统开销也非常大，所以即使是现在的操作系统也不做环的检测的，在出现死锁的情况的时候要么强制杀死一些进程，要么等到人工处理。
> 我遇到的是第二种，（由于E文不溜，大概是这个意思吧）函数执行过程中，某个捕捉到的异常的对象的ref
> count，python不会自动把它变为0，而且函数的栈帧python也会保留着，用于traceback。我把我的扫描器拿去扫上亿的ip，每次对某个ip的扫描中出现异常的时候，执行这个函数的栈帧都会被保留下来，引发异常的对象也会被保留下来，这样经过一个晚上，我的内存就被慢慢吃掉了。这种情况的解决办法很简单，我对引发异常的情况不感兴趣，因为几乎都是timeout引发的，在上面那个网页给了很明确的解决办法：sys.exc_traceback=None即可，强制python扔掉traceback信息。
> 第三种是在interactive模式下出现，我没看仔细，应该没有人能在interactive模式下慢慢玩到系统内存用完吧。。。
>
> that's all。
>

[张加林]

还是把代码贴出来吧：https://github.com/cainiaocome/web_shell_cmd/blob/master/web_shell_cmd.py

我一直没敢把代码贴出来，因为我最开始发现内存泄露的时候先去reddit问了的，结果被几个外国人骂了，因为我的代码进行了mass scan，他们还以为我是什么black hat，，，没办法删了帖子自己找的答案。

在 2015年2月7日星期六 UTC+8下午7:57:55，张加林写道：

[Leo Jay]

2015-02-09 17:31 GMT-08:00 张加林 <caini...@gmail.com>:
> 还是把代码贴出来吧：https://github.com/cainiaocome/web_shell_cmd/blob/master/web_shell_cmd.py
>
> 我一直没敢把代码贴出来，因为我最开始发现内存泄露的时候先去reddit问了的，结果被几个外国人骂了，因为我的代码进行了mass
> scan，他们还以为我是什么black hat，，，没办法删了帖子自己找的答案。
>

感觉你的代码有两个问题：
1. 为什么每3秒开一个线程？如果你 ip.china 文件足够大，你会开很多很多线程的。
2. 加锁解锁的写法不对，在加锁之后，应该用try ... finally，把解锁写在 finally 里，不然当中一旦出异常，你的代码就 hang 了。

--
Best Regards,
Leo Jay

[flyer]

在公司写的爬虫连续运行几个月了，在语言方面没遇到什么蛋疼的问题。

张加林 <caini...@gmail.com>于2015年2月7日星期六写道：

可重入还不会对最终结果造成影响的，加内存限制，超限重启是个相当简单便捷的方法，不过如果程序保存退出点的进度相当麻烦的话还是很蛋疼的。最近在写一个爬虫就相当蛋疼，一直没有条件可以让程序7x24小时的跑，就做一个进度保存，下次继续，手头上一直事情又多，到现在都还没去解决。

在 2015年2月7日星期六 UTC+8下午10:01:21，limodou写道：

简单的办法是加个内存限制，超限重启。特别是对于周期性运行的python程序。象supervisor这样的工具有这样的插件，不行可以自已写，如使用psutils来检查内存使用情况。

2015-02-07 19:57 GMT+08:00 张加林 <caini...@gmail.com>:

 刚刚学习python 的时候，看了不少文档，很多都有提到python的垃圾回收机制，当时以为从此和内存泄露说拜拜了，看来还是图样图僧破。

  前几天心血来潮，写了个扫描器，写完就想拿来试试，就从apnic下载了全球的ip分配表，写个脚本搞出中国的ip段，放到扫描器中扫描，然后睡觉去，准备早上起来看看结果。

  第二天起来，点亮屏幕的时候感觉特别慢，进去之后也感觉操作不对劲，立即top看了一下，扫描器占用了我60%的内存，当时心下一惊，wocao，遇到bug了。

  在网上摸了半天，终于找到源头：https://docs.python.org/2/reference/datamodel.html。

  在上面这个网页讲解__del__的地方谈到原来python也可能会出现内存泄露，第一种是出现在a->b , b->a的情况下，这个时候这两个对象的ref count永远不会变为0，python的垃圾回收器也就没法回收了。这个情况和操作系统的死锁似乎是一样的逻辑，都是由于在对资源（如果一个对象视为资源的话）的使用中出现了环，而对于环的检测非常困难，系统开销也非常大，所以即使是现在的操作系统也不做环的检测的，在出现死锁的情况的时候要么强制杀死一些进程，要么等到人工处理。

  我遇到的是第二种，（由于E文不溜，大概是这个意思吧）函数执行过程中，某个捕捉到的异常的对象的ref count，python不会自动把它变为0，而且函数的栈帧python也会保留着，用于traceback。我把我的扫描器拿去扫上亿的ip，每次对某个ip的扫描中出现异常的时候，执行这个函数的栈帧都会被保留下来，引发异常的对象也会被保留下来，这样经过一个晚上，我的内存就被慢慢吃掉了。这种情况的解决办法很简单，我对引发异常的情况不感兴趣，因为几乎都是timeout引发的，在上面那个网页给了很明确的解决办法：sys.exc_traceback=None即可，强制python扔掉traceback信息。

  第三种是在interactive模式下出现，我没看仔细，应该没有人能在interactive模式下慢慢玩到系统内存用完吧。。。

  that's all。

--

邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。

要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。

要发帖到此群组，请发送电子邮件至pyth...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--

I like python!
UliPad <<The Python Editor>>: http://code.google.com/p/ulipad/
UliWeb <<simple web framework>>: https://github.com/limodou/uliweb
My Blog: http://my.oschina.net/limodou

--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。
要发帖到此群组，请发送电子邮件至pyth...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--

时光飞逝，但时光正好。

[依云]

嗯，线程不是这么浪费的……用 concurrent.futures 里的线程池吧。Python 2.x
可以安装 futures 库，一样的。

锁的话，是可以使用 with 语句的哦，这样就不用手动写 try ... finally 了。

那个 .stop 方法是在干什么？.run 方法里也有很多不必要放在 self 上的属性。
把 IPNetwork 转成 list 再遍历完全没有必要，反而多占用内存，完全辜负了生
成器节约内存占用的本意。

--
Best regards,
lilydjwg

[Chunlin Zhang]

"为什么每3秒开一个线程？如果你 ip.china 文件足够大，你会开很多很多线程的。"

好像不会,楼主有一个50线程的上限吧

不过为什么要一直检查呢?而不是一开始就开50个,然后只要把异常处理好,这50个线程可以一直用到跑完为止吧?

不知道楼主在扫什么东东...扫漏洞吗?

--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---

您收到此邮件是因为您订阅了 Google 网上论坛上“python-cn(华蟒用户组,CPyUG 邮件列表)”群组中的主题。
要退订此主题，请访问https://groups.google.com/d/topic/python-cn/IfWg85-qbig/unsubscribe。
要退订此群组及其所有主题，请发送电子邮件到python-cn+...@googlegroups.com。

要向此群组发帖，请发送电子邮件至 pyth...@googlegroups.com。
要查看更多选项，请访问 https://groups.google.com/d/optout。

[小熊]

内存泄漏在:  list(netaddr.IPNetwork),  list 之后生成大量的IPAddress, IPNetwork 本身实现了 next, 直接迭代使用, 去除list后, 内存增长缓慢, 跑到3500行时,维持在400M. 

使用线程池(multiprocessing.dummy) 内存稳定在 200M

扫描全部公网ip干吗. 不是是想抓电信的光猫?  http://ipcn.chacuo.net/view/i_CHINANET 这样至少可以缩小50%工作量

[Leo Jay]

2015-02-09 19:20 GMT-08:00 Chunlin Zhang <zhangc...@gmail.com>:
> "为什么每3秒开一个线程？如果你 ip.china 文件足够大，你会开很多很多线程的。"
> 好像不会,楼主有一个50线程的上限吧
> 不过为什么要一直检查呢?而不是一开始就开50个,然后只要把异常处理好,这50个线程可以一直用到跑完为止吧?
>
> 不知道楼主在扫什么东东...扫漏洞吗?
>

嗯嗯，抱歉，把 while 错看成 if 了。

[Gelin Yan]

2015-02-10 12:56 GMT+08:00 小熊 <luw...@gmail.com>:

内存泄漏在:  list(netaddr.IPNetwork),  list 之后生成大量的IPAddress, IPNetwork 本身实现了 next, 直接迭代使用, 去除list后, 内存增长缓慢, 跑到3500行时,维持在400M. 

使用线程池(multiprocessing.dummy) 内存稳定在 200M

扫描全部公网ip干吗. 不是是想抓电信的光猫?  http://ipcn.chacuo.net/view/i_CHINANET 这样至少可以缩小50%工作量

这样看，似乎自身代码问题更多呢。和python关系不太大。 

[张加林]

贴出来的是poc代码，现在放在服务器上跑的代码已经改用IPNetwork提供的迭代器，对内存泄露也处理了，跑了两天了，内存占用稳定在30M。

抓的是一个中兴一个设备的后门，出厂自带

在 2015年2月10日星期二 UTC+8下午12:57:15，luw2007写道：

要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。
要发帖到此群组，请发送电子邮件至python-cn@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--

时光飞逝，但时光正好。

--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。

[张加林]

锁用with语句是什么意思？with open自带锁吗？

我记得在一个博文里看见说线程的结束得给线程设置一个标志，，，不过后来一直没看到过类似的说法，顺便问一下，那一个线程的run跑完的话是不是线程就自动退出了？

还有一个问题，我看见threading里边有一个active_count()方法，这个方法是得到所有的线程数吗？这里这个active是什么意思？

实际使用的代码已经改成使用IPNetwork的生成器了，内存占用大幅减少。

在 2015年2月10日星期二 UTC+8上午11:18:56，依云写道：

[依云]

On Tue, Feb 10, 2015 at 04:12:50AM -0800, 张加林 wrote:
> 锁用with语句是什么意思？with open自带锁吗？
> 我记得在一个博文里看见说线程的结束得给线程设置一个标志，，，不过后来一直没看到过类似的说法，顺便问一下，那一个线程的run跑完的话是不是线程就自动退出了？
> 还有一个问题，我看见threading里边有一个active_count()方法，这个方法是得到所有的线程数吗？这里这个active是什么意思？
> 实际使用的代码已经改成使用IPNetwork的生成器了，内存占用大幅减少。

lock = threading.Lock()

with lock:
do_something()

run 方法结束，线程就退出了。一些在 run 里 while True 不断地跑的线程，需
要通过一个标志来判断是不是该退出了。active 就是正在跑的线程嘛。


--
Best regards,
lilydjwg

Linux Vim Python 我的博客:
http://lilydjwg.is-programmer.com/
--
A: Because it obfuscates the reading.
Q: Why is top posting so bad?

[jianxiao jiang]

py不能做24x7的项目, 我和小伙伴们都惊呆了

--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---

您收到此邮件是因为您订阅了 Google 网上论坛的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。

[Zhou Scott]

GD AOS后端Server就是用Python写的。关键看代码怎么写吧。

在 2015年2月7日 下午8:36，猪猪 <cspi...@qq.com>写道：

Python不成熟，做做小玩意还行，但7*24的ServerAPP万万不可用Python。‍

--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---

您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。

[Gelin Yan]

gd aos是啥？

[MuSheng Chen]

没详细查证，之前记得看过某种说法，自己写__del__还是__delete__时，需要自己处理某些对象的释放。也就一直小心使用这两个方法。

[winiex]

正解。

On Sunday, February 8, 2015 at 12:03:32 PM UTC+8, HYRY wrote:

Python的垃圾回收缺省配置就能回收环。在Python 3.4之前如果定义了__del__的话，环回收可能会出问题：

Circular references which are garbage are detected when the option cycle detector is enabled (it’s on by default), but can only be cleaned up if there are no Python-level __del__() methods involved.

不过这个问题已经在Python 3.4中解决了。

https://docs.python.org/3.4/whatsnew/3.4.html#pep-442-safe-object-finalization

2015年2月7日土曜日 20時57分55秒 UTC+9 张加林:

[winiex]

Python 2 中自己实现了自己的内存分配池机制，低于预设值内存大小的对象的内存分配会在这个池中分配，而该池在 OS 层面看来是一大块预先就申请好了的内存。这种手段避免了 memory fragmentation。

Python 3 的细节我不清楚。

On Monday, February 9, 2015 at 10:15:25 AM UTC+8, Zhenbo Li wrote:

在 2015年2月9日 上午10:12，Chunlin Zhang <zhangc...@gmail.com> 写道：
>
>
> 2015-02-09 9:48 GMT+08:00 风间星魂 <fengjia...@gmail.com>:
>>
>> 可以自己手动分配内存的内存碎片能解决。比如C家族。。。。
>
> C也是一样阿,如果常驻内存跑久了一样有内存碎片阿, 什么叫做"自己手动分配内存的内存碎片"?


你可以一次性申请一段大内存，然后自己维护一个内存池

[shaung]

我理解的 Python 的 memory fragmentation 就是这个内存池内部的碎片。
归还内存的最小单位是 256k 的 arena，一个 arena 中哪怕只有一个 pool 还在使用，整个这 256k 内存就都不会被释放。
如果有很多 small object，池里无法复用的小块内存有可能越来越多，这时只好向系统申请新的内存，于是我们看到内存使用量在增长。

--

邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---

您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。

要发帖到此群组，请发送电子邮件至pyth...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--

Cheers,
Shaun

[CheeponLee]

坑多半是自己挖的，宝剑能杀人也能伤自己

在 2015年2月7日星期六 UTC+8下午8:37:04，cspigpig写道：

Python不成熟，做做小玩意还行，但7*24的ServerAPP万万不可用Python。‍

[est]

本来想回复一下你这段话的。但是几乎没一句都没说正确。。。懒得回复了。。。。。。。。

2015-02-07 21:48 GMT+08:00 猪猪 <cspi...@qq.com>:

首先我并不是贬低Python，我下到机器码，上到erlang，我都用。相比之下，我觉得Python非常优秀。我从前年开始让运维部门用Python，取得很好效果。

但是，我们也应该正视Python的缺点。Python太年轻，用户不多，很多方面的需求所对应的成熟解决方案也较少，因此，稳定性必然不如Java之流。所以我才建议，小玩意用Python写，很不错，但ServerAPP，还是不要给自己挖坑了。我知道目前有很多看起来不小的项目都用Python，但他们花了多少时间填坑，你们有了解过吗？

最后，还是那句话，用合适的工具，去做合适的事情。不要让狂热变成偏见。也许你是Python的铁粉，但客观才是你成长的动力。

--

[David Wong]

爬虫好说，把队列什么的都独立开来就好保存进度了，例如用redis做队列或去重库

在 2015年2月7日 下午10:58，张加林 <caini...@gmail.com>写道：

可重入还不会对最终结果造成影响的，加内存限制，超限重启是个相当简单便捷的方法，不过如果程序保存退出点的进度相当麻烦的话还是很蛋疼的。最近在写一个爬虫就相当蛋疼，一直没有条件可以让程序7x24小时的跑，就做一个进度保存，下次继续，手头上一直事情又多，到现在都还没去解决。

在 2015年2月7日星期六 UTC+8下午10:01:21，limodou写道：

简单的办法是加个内存限制，超限重启。特别是对于周期性运行的python程序。象supervisor这样的工具有这样的插件，不行可以自已写，如使用psutils来检查内存使用情况。

2015-02-07 19:57 GMT+08:00 张加林 <caini...@gmail.com>:

 刚刚学习python 的时候，看了不少文档，很多都有提到python的垃圾回收机制，当时以为从此和内存泄露说拜拜了，看来还是图样图僧破。

  前几天心血来潮，写了个扫描器，写完就想拿来试试，就从apnic下载了全球的ip分配表，写个脚本搞出中国的ip段，放到扫描器中扫描，然后睡觉去，准备早上起来看看结果。

  第二天起来，点亮屏幕的时候感觉特别慢，进去之后也感觉操作不对劲，立即top看了一下，扫描器占用了我60%的内存，当时心下一惊，wocao，遇到bug了。

  在网上摸了半天，终于找到源头：https://docs.python.org/2/reference/datamodel.html。

  在上面这个网页讲解__del__的地方谈到原来python也可能会出现内存泄露，第一种是出现在a->b , b->a的情况下，这个时候这两个对象的ref count永远不会变为0，python的垃圾回收器也就没法回收了。这个情况和操作系统的死锁似乎是一样的逻辑，都是由于在对资源（如果一个对象视为资源的话）的使用中出现了环，而对于环的检测非常困难，系统开销也非常大，所以即使是现在的操作系统也不做环的检测的，在出现死锁的情况的时候要么强制杀死一些进程，要么等到人工处理。

  我遇到的是第二种，（由于E文不溜，大概是这个意思吧）函数执行过程中，某个捕捉到的异常的对象的ref count，python不会自动把它变为0，而且函数的栈帧python也会保留着，用于traceback。我把我的扫描器拿去扫上亿的ip，每次对某个ip的扫描中出现异常的时候，执行这个函数的栈帧都会被保留下来，引发异常的对象也会被保留下来，这样经过一个晚上，我的内存就被慢慢吃掉了。这种情况的解决办法很简单，我对引发异常的情况不感兴趣，因为几乎都是timeout引发的，在上面那个网页给了很明确的解决办法：sys.exc_traceback=None即可，强制python扔掉traceback信息。

  第三种是在interactive模式下出现，我没看仔细，应该没有人能在interactive模式下慢慢玩到系统内存用完吧。。。

  that's all。

--

邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。

要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。

要发帖到此群组，请发送电子邮件至pyth...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--

I like python!
UliPad <<The Python Editor>>: http://code.google.com/p/ulipad/
UliWeb <<simple web framework>>: https://github.com/limodou/uliweb
My Blog: http://my.oschina.net/limodou

--

[Jian Wen]

https://github.com/cainiaocome/web_shell_cmd/blob/master/web_shell_cmd.py#L61
替换 except Exception,e 为 except Exception as e

https://www.python.org/dev/peps/pep-3110/

Semantic Changes

In order to resolve the garbage collection issue related to PEP 344 ,
except statements in Python 3 will generate additional bytecode to
delete the target, thus eliminating the reference cycle. The
source-to-source translation, as suggested by Phillip J. Eby [9] , is

try:
try_body
except E as N:
except_body
...

gets translated to (in Python 2.5 terms)

try:
try_body
except E, N:
try:
except_body
finally:
N = None
del N
...

An implementation has already been checked into the p3yk branch [10] .

--
Best,

Jian

[Jian Wen]

另外，还有一个有意思的和gc，traceback有关的问题
https://bitbucket.org/zzzeek/sqlalchemy/issue/2703

self._exc_info = None # remove the reference of traceback object manually

--
Best,

Jian

[zhendong huang]

哈哈哈

[lee Alexander]

一股浓浓的CTO腔

--

邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。
要发帖到此群组，请发送电子邮件至pyth...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--