查找 Perl 内存泄漏 [英] Finding a Perl memory leak

查看:22
本文介绍了查找 Perl 内存泄漏的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

已解决见编辑 2

你好

我一直在编写 Perl 程序来处理本地(专有)程序的自动升级(为我工作的公司).

I've been writing a Perl program to handle automatic upgrading of local (proprietary) programs (for the company I work for).

基本上,它通过 cron 运行,不幸的是有内存泄漏(或类似的东西).问题是只有在我不看的时候才会发生泄漏(也就是通过 cron 运行时,而不是通过命令行).

Basically, it runs via cron, and unfortunately has a memory leak (or something similar). The problem is that the leak only happens when I'm not looking (aka when run via cron, not via command line).

我的代码不包含任何循环(或其他)引用,所以常用的工具对我没有帮助(Devel::CycleDevel::Peek).

My code does not contain any circular (or other) references, so the commonly cited tools will not help me (Devel::Cycle, Devel::Peek).

我将如何弄清楚是什么使用了如此多的内存以致内核将其杀死?

How would I go about figuring out what is using so much memory that the kernel kills it?

基本上,代码 SFTP 进入服务器(使用 ```sftp...`` `),调用 OpenSSL 来验证文件,如果需要更多文件,然后更多 SFTP,并安装它们(解压它们).

Basically, the code SFTPs into a server (using ```sftp...`` `), calls OpenSSL to verify the file, and then SFTPs more if more files are needed, and installs them (untars them).

我在第一个 SFTP 会话之前看到了延迟(约 15 秒),但它从未使用过多的内存以致被杀死(在我面前).

I have seen delays (~15 sec) before the first SFTP session, but it has never used so much memory as to be killed (in my presence).

如果我不能解决这个问题,我将需要用不同的语言重新编写,这将花费宝贵的时间.

If I can't sort this out, I'll need to re-write in a different language, and that will take precious time.

以下消息由内核打印出来,让我相信这是内存泄漏:

The following message is printed out by the kernel which led me to believe it was a memory leak:

[100023.123] Out of memory: kill process 9568 (update.pl) score 325406 or a child
[100023.123] Killed Process 9568 (update.pl)

我不认为这是 cron 的问题,因为在通过命令行运行它时会出现停顿(有时约 15 秒).此外,没有使用环境变量(至少根据我所写的,也许底层的东西是这样做的?)

I don't believe it is an issue with cron because of the stalling (for ~15 sec, sometimes) when running it via the command-line. Also, there are no environmental variables used (at least by what I've written, maybe underlying things do?)

编辑 2: 我自己发现了这个问题,在 mobrule 的以下评论的帮助下(针对这个问题).事实证明,该脚本每天仅从用户(非 root)的 crontab 中调用一次,并且(非 root 权限)导致了特殊的无限循环情况.

Edit 2: I found the issue myself, with help from the below comment by mobrule (in response to this question). It turns out that the script was called from a crontab of a user (non-root) just once a day and that (non-root privs) caused a special infinite loop situation.

抱歉各位,我之前没有找到这个让我觉得有点愚蠢,但谢谢.

Sorry guys, I feel kinda stupid for not finding this before, but thanks.

mobrule,如果你提交你的评论作为答案,我会接受它,因为它会让我找到问题.

mobrule, if you submit your comment as an answer, I will accept it as it lead to me finding the problem.

结束编辑

谢谢,布莱恩

附言我也许可以发布一小段代码,但由于公司政策,我不能发布全部代码.

P.S. I may be able to post small snippets of code, but not the whole thing due to company policy.

推荐答案

你怎么知道是内存泄漏?我可以想到操作系统会杀死程序的许多其他原因.

How do you know that it's a memory leak? I can think of many other reasons why the OS would kill a program.

我要问的第一个问题是这个程序是否总是从命令行正常运行?".如果答案是否",那么我会先解决这些问题.

The first question I would ask is "Does this program always work correctly from the command line?". If the answer is "No" then I'd fix these issues first.

另一方面,如果答案是是",我会调查在 cron 下执行程序和从命令行执行程序之间的所有差异,以找出它行为不端的原因.

On the other hand if the answer is "Yes", I would investigate all the differences between having the program executed under cron and from the command line to find out why it is misbehaving.

这篇关于查找 Perl 内存泄漏的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆