我打印出每次线程迭代后的可用空间,所以我可以慢慢地看下去.现在还有趣的是它每次都不会减少.有时,循环后的空闲内存将保持不变.
我在Linux 2.6上使用从源代码构建的Perl 5.8.8
有人有任何想法,甚至有什么可能是造成这个的建议？我正在考虑将我的Perl升级到更高版本,以排除Perl内核中的内存泄漏.
更新：这可能是一个线程堆栈大小问题？我可以为堆栈分配比我需要的更多的内存.当我创建我的线程时,我不会将设置从默认值更改.我是不是该？线程doc表示默认值通常为16MB,具体取决于系统. 16×10线程= 160MB – >这可能是罪魁祸首.思考？
更新：我构建并安装Perl 5.12.1并重建模块和所有内容.现在运行脚本大约一个小时,这是我注意到的.内存使用现在可以管理,但不是理想的.
在开始之后,我的线程似乎有点下降.从〜60-66MB下降到我的10个线程〜〜45-50MB.
>经过一些迭代,他们的使用总共增加了3MB(大致相同于之前).
>到目前为止,我的预期是.所有的内存都是为了生成的,然后只是一点点我在线程中使用的变量.这是我不喜欢的部分.跑了大约10分钟后,我又失去了65MB！为什么这样做？如果它已经迭代了几次,只有3MB,为什么要分配？
>在这一点上,它已经运行了一个半小时,而且还没有使用额外的65MB,还有84MB！
>它慢慢地需要更多的内存但是奇怪的是,可用内存量不是每次迭代减少.我打印出每次迭代之前和之后的空闲内存,它将保持一段时间或悬停 – 围绕一定数量一段时间,然后突然改变5-10MB.我不能离开这个运行超过一两天,因为它开始接近80/90％的可用内存.
还有其他想法吗？任何我可以尝试吗？我已经不了解我所有的变数.
更新：我真的想继续重新编译Perl与glibc作为最后的手段,因为我发现一些报告,在一些风格的Linux它将segfault.所以自从我上次发布以来,我进一步探讨了循环在我的散列的可能性.没有发现所以我花了最后几天分析我的子例程,并缓存在另一次迭代中使用的任何东西.每次都会重新创建大量的新东西,即使我明确地将其全部删除,Perl也不会清理它.所以如果不合作,我就不会毁了它.会看到缓存我的对象是否有帮助.将稍后发布内存使用统计信息.
更新：嗯,很奇怪即使缓存我的数据后再次使用,内存也以相同的速度上升.它开始更高,因为我正在缓存,但随着时间的推移,尽管它主要是使用我的缓存对象.这很困惑猜测是时候给glibc一个尝试吗？或者这只是选择Perl的一个缺点,每隔几天就要重新启动服务器.
更新：试过没有缓存,没有glibc,再次.工作一会儿,几个小时,然后开始增长.只是想让你看到一个图表.
http://tinypic.com/r/311nc08/3
http://i32.tinypic.com/311nc08.jpg
更新：这是一个在一分钟内每个线程之前和之后记录可用内存的日志.也许这可以帮助人们更好地了解问题.这似乎是稳定的,然后每一次都会像这样吃更多的记忆.这里我输了差不多40 MB！
[9:8:30,Fri Jul 23,2010] [0] Memory usage at end thread 1: 253.812736MB (obj cache: 136) [9:8:30,2010] [0] Memory usage at idle thread 1: 253.812736MB (obj cache: 136) [9:8:34,2010] [204] Sending data to thread [9:8:34,2010] [0] 3 - Creating a new obj [9:8:34,2010] [206] Sending data to thread [9:8:34,2010] [0] 4 - Creating a new obj [9:8:35,2010] [0] Memory usage at end thread 3: 253.812736MB (obj cache: 136) [9:8:35,2010] [0] Memory usage at idle thread 3: 253.812736MB (obj cache: 136) [9:8:35,2010] [0] Memory usage at end thread 4: 253.812736MB (obj cache: 136) [9:8:35,2010] [0] Memory usage at idle thread 4: 253.812736MB (obj cache: 136) [9:8:41,2010] [225] Sending data to thread [9:8:41,2010] [0] 2 - Creating a new obj [9:8:42,2010] [0] Memory usage at end thread 2: 253.681664MB (obj cache: 136) [9:8:42,2010] [0] Memory usage at idle thread 2: 253.681664MB (obj cache: 136) [9:8:47,2010] [243] Sending data to thread [9:8:47,2010] [0] 1 - Creating a new obj [9:8:48,2010] [0] Memory usage at end thread 1: 253.935616MB (obj cache: 136) [9:8:48,2010] [0] Memory usage at idle thread 1: 253.935616MB (obj cache: 136) [9:9:1,2010] [277] Sending data to thread [9:9:1,2010] [0] 3 - Creating a new obj [9:9:2,2010] [280] Sending data to thread [9:9:2,2010] [0] 4 - Creating a new obj [9:9:2,2010] [0] Memory usage at end thread 3: 253.935616MB (obj cache: 136) [9:9:2,2010] [0] Memory usage at idle thread 3: 253.935616MB (obj cache: 136) [9:9:3,2010] [283] Sending data to thread [9:9:3,2010] [0] 2 - Creating a new obj [9:9:4,2010] [284] Sending data to thread [9:9:4,2010] [0] 1 - Creating a new obj [9:9:4,2010] [0] Memory usage at end thread 2: 253.935616MB (obj cache: 136) [9:9:4,2010] [0] Memory usage at idle thread 2: 253.935616MB (obj cache: 136) [9:9:5,2010] [287] Sending data to thread [9:9:5,2010] [0] 3 - Creating a new obj [9:9:5,2010] [0] Memory usage at end thread 4: 253.93152MB (obj cache: 136) [9:9:5,2010] [0] Memory usage at idle thread 4: 253.93152MB (obj cache: 136) [9:9:6,2010] [290] Sending data to thread [9:9:6,2010] [0] 2 - Creating a new obj [9:9:7,2010] [0] Memory usage at end thread 3: 253.804544MB (obj cache: 136) [9:9:7,2010] [0] Memory usage at idle thread 3: 253.804544MB (obj cache: 136) [9:9:7,2010] [0] Memory usage at end thread 1: 253.804544MB (obj cache: 136) [9:9:7,2010] [0] Memory usage at idle thread 1: 253.804544MB (obj cache: 136) [9:9:9,2010] [0] 4 - Creating a new obj [9:9:9,2010] [301] Sending data to thread [9:9:9,2010] [0] 3 - Creating a new obj [9:9:9,2010] [302] Sending data to thread [9:9:9,2010] [0] 1 - Creating a new obj [9:9:10,2010] [0] 3 - Creating a new obj [9:9:11,2010] [0] Memory usage at end thread 4: 253.93152MB (obj cache: 136) [9:9:11,2010] [0] Memory usage at idle thread 4: 253.93152MB (obj cache: 136) [9:9:12,2010] [308] Sending data to thread [9:9:12,2010] [0] 4 - Creating a new obj [9:9:13,2010] [0] Memory usage at end thread 1: 253.804544MB (obj cache: 136) [9:9:13,2010] [0] Memory usage at idle thread 1: 253.804544MB (obj cache: 136) [9:9:14,2010] [0] Memory usage at end thread 4: 253.804544MB (obj cache: 136) [9:9:14,2010] [0] Memory usage at idle thread 4: 253.804544MB (obj cache: 136) [9:9:14,2010] [0] Memory usage at end thread 3: 253.93152MB (obj cache: 136) [9:9:14,2010] [0] Memory usage at idle thread 3: 253.93152MB (obj cache: 136) [9:9:15,2010] [313] Sending data to thread [9:9:15,2010] [0] 1 - Creating a new obj [9:9:16,2010] [0] Memory usage at end thread 2: 214.482944MB (obj cache: 136) [9:9:16,2010] [0] Memory usage at idle thread 2: 214.482944MB (obj cache: 136) [9:9:16,2010] [315] Sending data to thread [9:9:16,2010] [0] 4 - Creating a new obj [9:9:17,2010] [0] Memory usage at end thread 1: 214.355968MB (obj cache: 136) [9:9:17,2010] [0] Memory usage at idle thread 1: 214.355968MB (obj cache: 136) [9:9:18,2010] [316] Sending data to thread [9:9:18,2010] [0] 3 - Creating a new obj [9:9:18,2010] [317] Sending data to thread [9:9:18,2010] [0] 2 - Creating a new obj [9:9:18,2010] [318] Sending data to thread [9:9:18,2010] [0] 1 - Creating a new obj [9:9:19,2010] [0] Memory usage at end thread 4: 214.355968MB (obj cache: 136) [9:9:19,2010] [0] Memory usage at idle thread 4: 214.355968MB (obj cache: 136) [9:9:19,2010] [0] Memory usage at end thread 1: 214.355968MB (obj cache: 136) [9:9:19,2010] [0] Memory usage at idle thread 1: 214.355968MB (obj cache: 136) [9:9:20,2010] [0] Memory usage at end thread 3: 214.482944MB (obj cache: 136) [9:9:20,2010] [0] Memory usage at idle thread 3: 214.482944MB (obj cache: 136) [9:9:20,2010] [0] Memory usage at end thread 2: 214.482944MB (obj cache: 136) [9:9:20,2010] [0] Memory usage at idle thread 2: 214.482944MB (obj cache: 136)
UPDATE(8/12/2010)：只需运行一个新的Perl 5.12编译版本的线程和系统malloc.奇怪的是我得到了同样的行为.一次失去一大堆MB.可能尝试Valgrind看看为什么我失去了它.虽然我在想别的东西,但我在玩弄别的东西.我的脚本创建和破坏(据称)许多SSL套接字. IO :: Socket :: SSL等广泛使用的模块有可能泄漏一点吗？还是OpenSSL？ (使用v0.9.8o).要尝试同步访问SSL模块以查看是否有任何影响,线程访问可能会遇到问题.
更新：尝试在每个线程中分别加载模块,更快的内存使用.尝试使用套接字功能来锁定区域,所以一次只有一个线程使用它们,仍然与之前相同.将工作线程数从4增加到10,工作量完全相同.内存没有持续30分钟.引导我相信它是内部线程实现的一个Perl问题,或堆栈问题(不是双关语).我尝试使用内置的线程方法来更改堆栈大小,但结果相同.去寻找另一种方式.也许是较低级的方式.增加线程数使内存更快…似乎是线程堆栈实现或堆栈大小的东西
UPDATE(9/15/2010)：在IO :: Socket :: SSL文档中找到这个有趣的tidbit …
This is due to the fact that a circular reference is required to make IO::Socket::SSL sockets act simultaneously like objects and glob references.
“通函”嗯？另一个可能的解释是这些套接字一直在坚持一段时间,尽管我明确地将它们定义为undef’d他们.去看看Weaken,看看这是否与套接字有任何关系.如果我发现有趣的话会让你知道
SOLVED(9/16/2010)：看到我发布的包含该解决方案的答案
解决方法
> 5.12 :: @_和$_不再泄漏线程(RT#34342和#41138,也#70602,#70974)’
> 5.10 ::在ithreads下面,PL_reg_curpm中的正则表达式现在被引用计数.这消除了很多恶意的解决方法来应对它,而不是被引用计数.
> 5.9 :: threads：几个修复,例如join()问题和内存泄漏.在一些使用glibc的平台(如Linux)中,一个ithread的最小内存占用已经减少了几百千字节.
> 5.9 :: threads :: shared许多内存泄漏已被修复.
我的意思是,当你谈到四年的发展和可能导致这个问题的各种各样的东西,看看现在的threads::shared的更新日
我对你的帖子发表了评论,这将是我的下一组建议：如果您不使用glibc,并且使用perl malloc(默认),则永远不会将内存释放到操作系统.进程大小将代表perl每次占用的最大大小.尝试使用glibc malloc重建(需要重新编译),看是否提供了不同的内存配置文件.除此之外,它将是时候显示代码.