Fatal error: Out of memory, but I do have plenty of memory (PHP)

前端 未结 20 2553
情歌与酒
情歌与酒 2020-11-29 23:34

Since my question is getting longer and longer, I decide to re-write the whole question to make it better and shorter.

I run my website on dedicated server with 8GB

相关标签:
20条回答
  • 2020-11-29 23:58

    For starters, memory_get_peak_usage() will not be helpful here. It will only return the amount of memory which was allocated, and that is the same number which caused the error.

    memory_get_usage will return the active amount of memory which is being allocated when it is called.

    ini_set('memory_limit', '256M'); will set the maximum allowance of PHP's footprint on your systems Memory. If you are getting OOM at 768K, upping it will not fix the problem.

    There is no indication as to what version of PHP you are using, but I would suggest an upgrade immediately. There are several bugs where Zend's Memory Manager fails to deallocate memory, which would lead you exactly to the same problem.

    Are both your local server and your production server running the same version of OS, the same long bit and the same version of PHP? The answer will be no.

    If it is unrelated to the windows malloc() issue, being it is a sub domain and probably within a VirtualHost, and allocating only 768k, it almost sounds like an OS issue.

    Run tasklist from the command prompt when you access your script. Do you see an additional Apache thread, or Memory usage across the processes spike?

    One last idea is, run flush() and/or ob_flush(); after each loop for the table row/column. This should clear your buffer and save you some memory in the event this is where the issue is occurring.

    0 讨论(0)
  • 2020-11-29 23:59

    I would say the server is running out of physical/swap memory, so PHP can't allocate enough memory.

    Can you paste the output of free here?

    0 讨论(0)
  • 2020-11-30 00:01

    Just to recap (I'm adding this answer quite a distance from the original question):

    • PHP is unable to allocate what appears to be a small amount of memory
    • the current memory usage at the time the error occrs + the requested amount is less than the memory limit currently in force
    • the system has 6Gb available for use by PHP when this occurs
    • since the problem is resolved by restarting apache - it's apache which is preventing the memory from beig available to PHP

    If these are all valid then the only possible explanation is that the 6Gb is very fragmented - which I think is a little unlikely. You didn't say how PHP is invoked from Apache - mod_php? fpm? Fcgi?

    I would start by examining each of the above predicates - particularly the free memory one. How do you know that there's 6Gb free when the error occurs? A more likely cause is that there's a memory leak occurring which you're not spotting.

    You've not provided any details of how apache is configured; I'd also have a look at reducing MaxRequestsPerChild and MaxMemFree. (I'm not very familiar with worker apache where this will apply per thread - really you need a limit per process). If you provided the core setting from the apache config then maybe we could make further suggestions.

    Unless you are using Ajax extensively, make sure your keepalive time is 2 or less.

    0 讨论(0)
  • 2020-11-30 00:01

    The following two facts definitely point to memory leaks:

    1. The error appears at different lines in your code,
    2. The error reports a relatively small memory allocation.

    I would first single out PDO, disabling all the other extensions and let it run overnight using something like Siege / Apache Bench (ab). You could also try running it using the cli interface (just make sure you keep the same memory limits).

    You could use the memory_get_peak_usage() function at the end of your script to see how much memory PHP thinks it has been using.

    From your comment that's 800 kB, which is okay; definitely not the gigantic amount of memory that would cause an out-of-memory ;-)

    Lastly, though I wouldn't recommend upgrading to 5.4 at this point, upgrading to the latest 5.3.x is probably worth it due to multiple vulnerabilities and leaks that have been addressed since 5.3.1

    0 讨论(0)
  • 2020-11-30 00:02

    I ran accross the same kind of problem with the server dying when trying to use the swap. This is because mod_php does not free memory ever. So Apache processes keep growing either reaching apache or PHP's memory limit or, if there's no limit, crashing the server.

    Restarting apache makes it to spawn new fresh slim processes but as they run PHP scripts over time, they grow until problems arise.

    The solution is to make apache to kill processes after a certain number of queries served so it will create new ones ( There are some questions related to that) reducing the MaxRequestsPerChild configuration option to, let's say 100 (Defaults to 1000).

    Of course this may reduce server performances as it takes ressources to kill and spawn new processes but at least it keeps the site working. You might be tempted to raise the number of running processes to keep performances high, be sure PHP (or apache) memory limit x max number of processes do not get over your server's physical ram.

    Here's my experience, hope it helps.

    0 讨论(0)
  • 2020-11-30 00:03

    I would start by upgrading PHP to 5.4+ as it's up to 50% faster for some applications. They fixed a large number of memory leaks. Please see becnhamrks: http://news.php.net/php.internals/57760

    0 讨论(0)
提交回复
热议问题