This is really weird, because it included really important fixes for not really working and causing WSOD 3.1.13 version, so we have included APC 3.1.14 in BOA-2.0.6-dev already. The problem is that we can still use it, because we are using our mirrored copy, but after reading some explanations from Rasmus, it is not clear (?) if we should wait for APC 3.1.15 or just go with APC 3.1.14 we have archived, or downgrade to known as broken 3.1.13. Now we don't even know if 3.1.14 caused issues also for older PHP versions, or maybe for 5.4 we don't use anyway. What a mess!

Comments

omega8cc’s picture

I guess the next step is to actually *check* if APC 3.1.14 really didn't work for PHP 5.2.17 and PHP 5.3.21 we have in BOA-2.0.6-dev

For reference: https://bugs.php.net/bug.php?id=63909

[2013-01-08 00:45 UTC] rasmus@php.net
Maybe it is config-related somehow. I tried a bunch of different PHP versions 
with APC 3.1.14 today and they all worked. But all my configs were close to 
this:

extension = apc.so
apc.enabled = 1
apc.shm_segments = 1
apc.optimization = 0
apc.shm_size = 384M
apc.ttl = 7200
apc.user_ttl = 7200
apc.num_files_hint = 1024
apc.mmap_file_mask = /tmp/apc.XXXXXX
apc.enable_cli = 1
apc.cache_by_default = 1
apc.include_once_override = 1
apc.stat = 1
apc.stat_ctime = 1
omega8cc’s picture

Priority: Major » Critical

So, before I even started any testing, we have got a clear answer, confirming what Rasmus mentioned about serious memory issues - just see what happened on the Linode VPS running BOA-2.0.6-dev: https://gist.github.com/omega8cc/4756875 - PHP-FPM took over all memory and CPU and caused parent system to kill mysql processes. Not nice.

omega8cc’s picture

Status: Active » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.