blocks|key|342095|text|在没有看到任何代码的情况下，很难说出原因。然而，一个典型的问题是递归引用，即。对象A指向对象B，反之亦然，这可能会导致GC搞砸。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|342096|我不知道您当前是如何处理该文件的，但您可以尝试一次只读取一行文件。如果一次读取整个文件，可能会消耗更多内存。|342097|这实际上是我经常更喜欢Python处理批处理任务的原因之一。|342098|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

It's difficult to say the cause without seeing any code. However, a typical issue is recursive references, ie. object A points to object B and the other way around, which may cause the GC to screw up.

I don't know how you're currently processing the file, but you could attempt to only read the file one row at a time. If you read the whole file at once it may consume more memory.

This is actually one of the reasons I often prefer Python for batch processing tasks.

blocks|key|339750|text|这取决于你在处理完变量后如何清除它们。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|339751|看起来您已经处理完了记录，但是您仍然将信息存储在某个地方。如果有疑问，可以使用unset()清除变量。|offset|length|339752|如果没有帮助，请提供一个最小的再现代码示例，看看所有的内存都到哪里去了。|339753|顺便说一句，生成重现问题的最小代码样本是一种很好的调试技术，因为它会迫使您仔细地重新检查代码。|339754|entityMap|0|LINK|mutability|MUTABLE|url|http://us3.php.net/manual/en/function.unset.php^0|0|13|7|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@$D|T|E|U|1|V]]|A|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|X|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]]]

It depends on how are you clearing the variables after being done with them.

It looks like you are done with the record but you are still storing the information somewhere. Use <a href="http://us3.php.net/manual/en/function.unset.php" rel="nofollow noreferrer">unset()</a> to clear variables up if in doubt.

Please provide a minimal reproducing code sample to see where is all that memory going if this doesn't help. 

BTW, producing the smallest code sample that will reproduce the problem is a great debugging technique because it forces you to go through the code again, with care.

blocks|key|338705|text|查看一下代码会有所帮助，但如果您想自己调试它，可以查看Xdebug，它将有助于分析您的应用程序。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|338706|当然，根据您正在做的事情，它可能正在积累一些内存，尽管132MB对于2500条记录来说似乎已经很高了。当然，如果需要，您可以在php.ini中使用tweak+your+memory+limit。|338707|您正在读取的CSV文件有多大？您对它进行了哪些对象和类型的处理？|338708|entityMap|0|LINK|mutability|MUTABLE|url|http://www.xdebug.org/|1|http://www.php.net/manual/en/ini.core.php#ini.memory-limit^0|R|6|0|0|21|N|1|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@$A|S|B|T|1|U]]|C|$]]|$1|D|3|E|5|6|7|V|8|@]|9|@$A|W|B|X|1|Y]]|C|$]]|$1|F|3|G|5|6|7|Z|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|10|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]|P|$5|K|L|M|C|$N|Q]]]]

It would help to have a look at the code but if you want to debug it yourself, have a look at <a href="http://www.xdebug.org/" rel="noreferrer">Xdebug</a>, it'll help profile your application.

Of course, depending on what you are doing, it is possible it's accumulating some memory, although 132MB seems already high for 2500 records. Of course, you can <a href="http://www.php.net/manual/en/ini.core.php#ini.memory-limit" rel="noreferrer">tweak your memory limit</a> in php.ini if needed.

How big is the CSV file you are reading? And what objects and kind of processing are you doing to it?

blocks|key|3320226|text|您是如何读取该文件的？如果您使用的是fread/filegetcontent或其他类似的函数，那么您将消耗内存中的整个文件大小(或者无论使用fread加载多少)，因为整个文件都是在调用时加载的。然而，如果你使用fgetcsv，如果一次只读一行，取决于一行的长度，这在你的记忆中可能会非常容易。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3320227|还要确保在每个循环中重用尽可能多的变量。检查是否没有包含大量数据的数组。|3320228|作为最后一个注意事项，还要确保您在循环之前打开文件，然后在循环之后关闭它：|3320229|$fh+=+fopen(...);
while(true)
{
//...
}
fclose($fh);|code-block|syntax|javascript|3320230|你并不是真的想这样做：|3320231|while(true)
{
$fh+=+fopen(...);
//...
fclose($fh);
}|3320232|就像其他人所说的，如果不看一些代码就很难判断。|3320233|entityMap|0|LINK|mutability|MUTABLE|url|http://php.net/fgetcsv^0|2X|7|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@$A|11|B|12|1|13]]|C|$]]|$1|D|3|E|5|6|7|14|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|15|8|@]|9|@]|C|$]]|$1|H|3|I|5|J|7|16|8|@]|9|@]|C|$K|L]]|$1|M|3|N|5|6|7|17|8|@]|9|@]|C|$]]|$1|O|3|P|5|J|7|18|8|@]|9|@]|C|$K|L]]|$1|Q|3|R|5|6|7|19|8|@]|9|@]|C|$]]|$1|S|3|-4|5|6|7|1A|8|@]|9|@]|C|$]]]|T|$U|$5|V|W|X|C|$Y|Z]]]]

How are you reading the file? If your using fread/filegetcontents or other such functions then you are going to consume the entire file size (or however much you load with fread) in memory as the entire file is loaded at call time. However if you use <a href="http://php.net/fgetcsv" rel="nofollow noreferrer">fgetcsv</a> if will only read one line at a time depending on the length of the line this can be dramaticly easier on your memory.

Also make sure that you are reusing as many variables as possible on each loop. Check that there are no array with large amounts of data in them.

As a last note also make sure that you are opening your file before your loop then closing it afterwords:

<pre><code>$fh = fopen(...);
while(true)
{
//...
}
fclose($fh);
</code></pre>

You don't realy want to be doing this:

<pre><code>while(true)
{
$fh = fopen(...);
//...
fclose($fh);
}
</code></pre>

And like others have said it'll be hard to tell without seeing some code.

blocks|key|3320248|text|你能在你的php.ini中改变你的memory_limit吗？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3320249|另外，对变量执行unset($var)会释放一些内存吗？$var+=+null也能帮上忙吗？|3320250|另请参阅此问题：What's+better+at+freeing+memory+with+PHP:+unset()+or+$var+=+null|offset|length|3320251|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/584960/whats-better-at-freeing-memory-with-php-unset-or-var-null^0|0|0|8|1S|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@$F|S|G|T|1|U]]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

Are you able to change your memory_limit in your php.ini?

Also, could doing unset($var) on variables free up some memory? Could $var = null help too?

See also this question: <a href="https://stackoverflow.com/questions/584960/whats-better-at-freeing-memory-with-php-unset-or-var-null">What&#39;s better at freeing memory with PHP: unset() or $var = null</a>

blocks|key|339929|text|如果您确实怀疑脚本中只有一两个内存泄漏导致它崩溃，那么您应该执行以下步骤：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|339930|339931|将memory_limit更改为较小的值，如500KB|unordered-list-item|offset|length|style|CODE|339932|注释掉应用于每行的所有处理步骤，只保留一个。|339933|对整个CSV文件运行有限的处理，看看是否可以再添加更多的步骤，并观察内存使用是否会激增。|339934|339935|示例：|339936|ini_set('memory_limit',+1024+*+500);
$fp+=+fopen("test.csv",+'r');
while($row+=+fgetcsv($fp))+{
++++validate_row($row);+++++++++//+step+1:+validate
++++//+add+these+back+in+one+by+one+and+keep+an+eye+on+memory+usage
++++//calculate_fizz($row);+++++//+step+2:+fizz
++++//calculate_buzz($row);+++++//+step+3:+buzz
++++//triangulate($row);++++++++//+step+4:+triangulate
}
echo+"Memory+used:+",+memory_get_peak_usage(),+"\n";|code-block|syntax|javascript|339937|最糟糕的情况是，您的所有处理步骤的效率都比较低，您需要对所有步骤进行优化。|339938|entityMap^0|0|0|1|C|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|10|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|11|8|@$F|12|G|13|H|I]]|9|@]|A|$]]|$1|J|3|K|5|E|7|14|8|@]|9|@]|A|$]]|$1|L|3|M|5|E|7|15|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|16|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|17|8|@]|9|@]|A|$]]|$1|Q|3|R|5|S|7|18|8|@]|9|@]|A|$T|U]]|$1|V|3|W|5|6|7|19|8|@]|9|@]|A|$]]|$1|X|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]]|Y|$]]

If you do in fact suspect that there are just one or two memory leaks in your script which are causing it to crash, then you should take the following steps:

<ul>
<li>Change <code>memory_limit</code> to something small, like 500KB</li>
<li>Comment out all but one of the processing steps which is applied to each row.</li>
<li>Run the limited processing over the whole CSV file and see if it can complete.</li>
<li>Gradually add more steps back in and watch to see if memory usage spikes.</li>
</ul>

Example:

<pre><code>ini_set('memory_limit', 1024 * 500);
$fp = fopen("test.csv", 'r');
while($row = fgetcsv($fp)) {
 validate_row($row); // step 1: validate
 // add these back in one by one and keep an eye on memory usage
 //calculate_fizz($row); // step 2: fizz
 //calculate_buzz($row); // step 3: buzz
 //triangulate($row); // step 4: triangulate
}
echo "Memory used: ", memory_get_peak_usage(), "\n";
</code></pre>

The worst case scenario is that all of your processing steps are moderately inefficient and you will need to optimize all of them.

blocks|key|339940|text|您可以尝试本地安装php5.3并调用http://www.php.net/manual/en/function.gc-collect-cycles.php。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|339941|339942|+gc_collect_cycles+-强制收集任何现有的垃圾循环|blockquote|style|CODE|339943|339944|339945|如果情况有所改善，您至少验证了问题的存在。|339946|entityMap|0|LINK|mutability|MUTABLE|url|http://www.php.net/manual/en/function.gc-collect-cycles.php^0|I|1N|0|0|0|1|H|0|0|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@$A|W|B|X|1|Y]]|C|$]]|$1|D|3|-4|5|6|7|Z|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|10|8|@$A|11|B|12|H|I]]|9|@]|C|$]]|$1|J|3|-4|5|6|7|13|8|@]|9|@]|C|$]]|$1|K|3|-4|5|6|7|14|8|@]|9|@]|C|$]]|$1|L|3|M|5|6|7|15|8|@]|9|@]|C|$]]|$1|N|3|-4|5|6|7|16|8|@]|9|@]|C|$]]]|O|$P|$5|Q|R|S|C|$T|U]]]]

you could try a local installation of php5.3 and call http://www.php.net/manual/en/function.gc-collect-cycles.php.

<blockquote>
 <code>gc_collect_cycles</code> — Forces collection of any existing garbage cycles
</blockquote>

if the situation improves, you at least verified (on of) the problem(s).

blocks|key|3107457|text|我也遇到了同样的问题，这也是由于数据库分析(Zend_Db_Profiler_Firebug)。在我的例子中，它是每分钟泄漏1mb。这个脚本应该运行几天，所以它会在几个小时内崩溃。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3107458|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I was having the same problem, and it was also due to database profiling (Zend_Db_Profiler_Firebug). In my case it was leaking 1mb per minute. this script was supposed to run for days, so it would crash within a few hours.

My PHP app has an import script that can import records.

At the moment, it is importing from a CSV file. It is reading each line of the CSV file, one line at a time using fgetcsv, and for each line it is doing a lot of processing on that record, including database queries, and then moving on to the next line. It shouldn't need to keep accumulating more memory.

After around 2500 records imported, PHP dies, saying that it has run over its memory limit (132 MB or so).

The CSV file itself is only a couple of megs - the other processing that happens does a lot of string comparisons, diffs, etc. I have a huge amount of code operating on it and it would be difficult to come up with a 'smallest reproducing sample'.

What are some good ways to go about finding and fixing such a problem?

Cause of problem found

I have a debug class which logs all my database queries during runtime. So those strings of SQL, some 30KB long, were staying in memory. I realise this isn't suitable for scripts designed to run for a long time.

There may be other sources of memory leaks, but I am fairly sure this is the cause of my problem.

How to go about fixing a memory leak in PHP

数据库

Python

我的PHP应用程序有一个可以导入记录的导入脚本。目前，它是从CSV文件导入的。它使用fgetcsv一次一行地读取CSV文件的每一行，并对每一行对该记录执行大量处理，包括数据库查询，然后转到下一行。它不应该需要不断积累更多的内存。在导入了大约2500条记录之后，PHP就死了，说它已经超出了它的内存限制(132MB左右)。...

问如何修复PHP中的内存泄漏
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何修复PHP中的内存泄漏EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何修复PHP中的内存泄漏
EN