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

查看:82
本文介绍了查找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?

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

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?)

我自己找到了问题,并在下面的评论中得到了帮助(针对此问题).事实证明,该脚本每天仅从用户(非root用户)的crontab中调用一次,并且(非root用户privs)导致了特殊的无限循环情况.

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, if you submit your comment as an answer, I will accept it as it lead to me finding the problem.

结束编辑

谢谢, 布莱恩

P.S.由于公司政策的缘故,我也许可以发布一些小的代码段,但不能发布全部代码.

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天全站免登陆