PHP unable to allocate memory
Solution 1
That is definitely the error you get when APC runs out of memory. When I (re)build servers, I often forget to increase this value to 128 M (suitable for my application) and that is the exact error you see.
Solution 2
Any failcounts in /proc/bc/resources?
All failcounts should be 0 or stay same since the last incident.
You need to:
-
Increase the resource limits with
vzct set <CTID> ... --save
on the resources that have fail counts (seeman vzctl
the set section). You can also modify the resource limits directly in/etc/vz/conf/
. Probably in all cases you need to reboot the containers after increasing the limits.To be safe, increase the settings (both barrier and limit) for problematic resources to x2 (twice) the maxheld.
-
Write down the current fail counts and keep an eye on them so that they don't increase any more.
For more info on controlling various resources, you can use http://wiki.openvz.org/Resource_shortage as a starting point.
Related videos on Youtube
Comments
-
Reece45 almost 2 years
On my way to the office this morning, every website on our shared VPS started giving the same error (several times, not the typical memory_limit error which is fatal):
Warning: Unknown: Unable to allocate memory for pool. in Unknown on line 0
The shared server is a 64-bit OpenVZ container running cPanel. There are only ~6 VPSes on the host-- this is the largest one at only 4GB. The host itself has 24GB RAM. As the below graphs show, the memory usage on the host and VPS are both rather low. CPU Usage/Disk/Host all seem to be normal. RlimitMem was set to
583653034
, yet the memory usage is about the same as it usually is.Apache 2.2, PHP 5.2 (mod_php)
Restarting Apache has corrected the problem for now. However, I'd like to prevent it from happening again and I'm not sure what was limiting the memory. RlimitMem was set to
583653034
, yet the memory usage is about the same as it usually is. There's seems to be plenty of memory: what caused this error?VPS Memory Usage
Host Memory Usage
APC Information
apc.ttl=0 apc.shm_size=0 apc.mmap_file_mask=(blank)
1 Segment(s) with 32.0 MBytes (mmap memory, pthread mutex locking)
-
Reece45 over 13 years5.5GB alloted through the VMs. Because OpenVZ is more containers than VMs, the file-cache is shared between them. The graph shows that 63.3% of the RAM is allocated to cache (which frees up immediately if needed), and 9% to buffers (There's actually a investigation in process to find out why it is so high (2GB) underway). In reality, its about only 3GB used (see serverfault.com/questions/9442/…)
-
Jeff Stice-Hall over 13 yearsAre you using APC with PHP? This may be related to stackoverflow.com/questions/3723316/…
-
Reece45 over 13 yearsSorry, it's 16GB, I failed at my math :). None of the utilise more than 50% (only 2 exceed 600MB usage)
-
Reece45 over 13 yearsAPC is installed, but it doesn't quite explain the problem. ttl was already set to 0, shm_size was only 32M (matched the value of kernel..shmmax). Bringing it up to 512M, it doesn't take long to bring that up to >32M (200M right now, after visiting a few of the websites). There are no user entries. Because of the speed that this memory is used up, wouldn't a "Unable to allocate memory for pool" show up more quickly?
-
Reece45 over 13 yearsWhy doesn't the error come up sooner? When I upped the value it filled the used memory reported by apc.php quickly exceeded the default max value.
-
hobodave over 13 years@AlR: You'd have to ask the developer or look at the code yourself. It wouldn't surprise me that APC leaks memory. There is an open bug report regarding this. The work around is what I already told you, increase your APC cache size.
-
hobodave over 13 years@AlR: Regarding the delay you are describing. The error doesn't occur simply because APC "fills" it's allocated memory. APC actually handles that by deleting older items from the cache and inserting the new one. Over time it gets wonky and can no longer do this. I'm assuming there is a memory leak.
-
Reece45 over 13 yearsFor another container (the 4GB one described above is 105, the problematic one is 189)
-
Reece45 over 13 yearsDoes the workaround prevent the issue from coming up at all, or does it just make it more rare? If it doesn't come up at all, is it because the 128M doesn't fill up?
-
hobodave over 13 years@AlR: It doesn't come up at all. At least not in the 7-21 days that go between us bouncing Apache. I see that you aren't using the user cache, just the opcode cache. There's really no good reason not to size your cache such that all of your PHP files can fit into it. With a 32M cache and your files taking up at least 200M you're really beating the hell out of APC with all the deletion/insertions that must be going on.
-
hobodave over 13 years@AlR: You could also go back to APC 3.0.9. That version worked fine for ages. Only with the 3.1 version did the developer start "fixing problems" that I had never experienced that lead to some serious wtf headaches.
-
Aleksandr Levchuk over 13 years@Reece, 105 and 189 - what resource is that for? privvmpages?
-
Reece45 over 13 years@hobodave Sounds like a better solution to me, for the time being. Thanks for your help!