After disabling APC on a web server with LAMP, sites began to work faster and the processor was offloaded. wtf?

Question

PHP

Hello colleagues and comrades.

We have a web server on CentOS 6.3 for hosting a number of sites on Drupal (mainly the seventh version), where the traditional LAMP + nginx is rolled up as a reverse proxy. APC was used as a precompiler for PHP. There are about 100 live sites on the server, there is no high load.

Most of the sites on the web server are recent, before that there were 5-6 sites and everything worked well (with the same APC). But when a lot of sites came (and all the newcomers are weak, 100 hosts per day), we began to notice periodic slowdowns: the same site loaded either normally, or with a dullness (and it was not possible to reproduce the dullness unambiguously). But when the sites started firing notices like Unable to allocate memory for pool...- they found the culprit, it turned out to be APC (that is, probably not him, but our imperfectdefault configs, but nevertheless).

The situation developed like this: The



fuss with the settings came down mainly to apc.shm_*, but the situation with the load on the processor did not solve it.

The full config at the time of shutdown was as follows:

APC Configuration

# cat /etc/php.d/apc.ini <br>
; Enable apc extension module<br>
extension = apc.so<br>
<br>
; Options for the APC module version >= 3.1.3<br>
; See http://www.php.net/manual/en/apc.configuration.php<br>
<br>
; This can be set to 0 to disable APC. <br>
apc.enabled=0<br>
; The number of shared memory segments to allocate for the compiler cache. <br>
apc.shm_segments=1<br>
; The size of each shared memory segment, with M/G suffixe<br>
apc.shm_size=6144M<br>
; A "hint" about the number of distinct source files that will be included or <br>
; requested on your web server. Set to zero or omit if you are not sure;<br>
apc.num_files_hint=2048<br>
; Just like num_files_hint, a "hint" about the number of distinct user cache<br>
; variables to store.  Set to zero or omit if you are not sure;<br>
apc.user_entries_hint=4096<br>
; The number of seconds a cache entry is allowed to idle in a slot in case this<br>
; cache entry slot is needed by another entry.<br>
apc.ttl=28800<br>
; use the SAPI request start time for TTL<br>
apc.use_request_time=1<br>
; The number of seconds a user cache entry is allowed to idle in a slot in case<br>
; this cache entry slot is needed by another entry.<br>
apc.user_ttl=28800<br>
; The number of seconds that a cache entry may remain on the garbage-collection list. <br>
apc.gc_ttl=3600<br>
; On by default, but can be set to off and used in conjunction with positive<br>
; apc.filters so that files are only cached if matched by a positive filter.<br>
apc.cache_by_default=1<br>
; A comma-separated list of POSIX extended regular expressions.<br>
apc.filters =  "-(.*)\.tpl\.php$, -(.*)/apc\.php$"<br>
; The mktemp-style file_mask to pass to the mmap module <br>
apc.mmap_file_mask=/tmp/apc.XXXXXX<br>
; This file_update_protection setting puts a delay on caching brand new files.<br>
apc.file_update_protection=2<br>
; Setting this enables APC for the CLI version of PHP (Mostly for testing and debugging).<br>
apc.enable_cli=0<br>
; Prevents large files from being cached<br>
apc.max_file_size=1M<br>
; Whether to stat the main script file and the fullpath includes.<br>
apc.stat=1<br>
; Vertification with ctime will avoid problems caused by programs such as svn or rsync by making <br>
; sure inodes have not changed since the last stat. APC will normally only check mtime.<br>
apc.stat_ctime=0<br>
; Whether to canonicalize paths in stat=0 mode or fall back to stat behaviour<br>
apc.canonicalize=0<br>
; With write_lock enabled, only one process at a time will try to compile an <br>
; uncached script while the other processes will run uncached<br>
apc.write_lock=1<br>
; Logs any scripts that were automatically excluded from being cached due to early/late binding issues.<br>
apc.report_autofilter=0<br>
; RFC1867 File Upload Progress hook handler<br>
apc.rfc1867=0<br>
apc.rfc1867_prefix =upload_<br>
apc.rfc1867_name=APC_UPLOAD_PROGRESS<br>
apc.rfc1867_freq=0<br>
apc.rfc1867_ttl=3600<br>
; Optimize include_once and require_once calls and avoid the expensive system calls used.<br>
apc.include_once_override=0<br>
apc.lazy_classes=0<br>
apc.lazy_functions=0<br>
; Enables APC handling of signals, such as SIGSEGV, that write core files when signaled. <br>
; APC will attempt to unmap the shared memory segment in order to exclude it from the core file<br>
apc.coredump_unmap=0<br>
; Records a md5 hash of files. <br>
apc.file_md5=0<br>
; not documented<br>
apc.preload_path<br>

As a result, APC was completely deactivated. The blunt sites disappeared, the processor was unloaded. "By eye" we do not see slower operation of sites, and therefore, until the circumstances were clarified, we left the server without an accelerator at all.

Colleagues, please share your experience on the topic (it can be bitter too) and tell me in which direction to turn the APC configs?

Answer 1

You are using some terribly large amount of memory for apc
apc.shm_size=6144M
it seems to me that it just searches the cache longer than it gives the code.

Answer 2

Unable to allocate memory for pool - you dig into their bugzilla, there are thousands of them. I am desperate to get APC to work properly in production using eAccelerator and XCache. I recommend to take fresh XCache.

Answer 3

PHP accelerators suffer from bugs. You are still lucky if he only ate memory, it happens that the PHP process crashes with a random probability and you won’t guess that the op cacher is to blame.

Answer 4

So he was already disabled at the time of the "shutdown"?

; This can be set to 0 to disable APC. 
apc.enabled=0

Or was it still included with that crazy amount of memory from the config?