WordPress站点上的APC缓存碎片

Question

I have recently installed and activated APC cache on a web server (Centos 5.7, PHP 5.3, 1.5Gb RAM) which is primarily dedicated to a medium traffic (30k unique visitors/mo) WordPress site running W3Total Cache which is set to use APC for database and object caching (page, minify use disk).

The APC info page for the server shows that there is consistently heavy fragmentation. For example, after restarting httpd, fragmentation is up to 75% after 11 hours, and I have seen it at 100% after a couple of days. At no time have I ever seen more than about 40% of cache memory used, and the server consistently runs at about 400Mb memory used, 1100Mb free (-/+ buffers/cache, as reported by free -m). So it doesn't appear to be lack of memory which is causing the fragmentation.

I started with the default APC and W3TC config, and have tried various combinations of the following changes:-

• apc.ttl reduced to 1800 (from 7200)
• apc.user_ttl set to 0 (the only thing using user cache is W3TC and it sets its own TTLs)
• W3TC timeout increased from 180 to 7200 secs
• apc.filters to block timthumb

None of these changes seem to have made much difference, though so far subjective performance and page load times measured by Google Webmaster Tools don't seem to have been affected either way.

Should I be worried about this? While current performance suggests not, I'd rather get this sorted before server load/site traffic rises. If it is of concern, what steps could I take to resolve?

EDIT:- Here's the full apc.ini config file:-

; Enable apc extension module
extension = apc.so

; Options for the APC module version >= 3.1.3
; See http://www.php.net/manual/en/apc.configuration.php

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

UPDATE I also posted on WP forums and got this response from the author of W3TotalCache:-

That experience is not unexpected on some sites. I will be working on the caching logic in the next release to improve APC performance.

So it seems like W3TotalCache is the root cause of the fragmentation.

Answer 1

Try increasing the size of the segment size used by APC. Use only one segment. Also access the wp admin interface from a subdomain you create.

Optimize APC Caching

If there are other vhosts on your server which does not need opcode caching, you can disable APC for these sites. You can do it on vhost level by setting apc.cache_by_default=0 in the apc.ini file, and put php_flag apc.cache_by_default On in the .htaccess file on your wp root directory. That should be the reason for the fragmentation.

Changes in the files also can cause fragmentation. The edited file will be deleted and the new file will be added to the cache. If you haven't done already, you should also set apc.stat=0 . This will improve the overall performance by not checking everytime if the files are changed or not.

If you don't want WP Admin to be cached you can create a subdomain like admin.example.com and you can access the admin panel. By doing like this you will be able to disable opcode caching. Which will also decrease fragmentation.

Update: Disabling object caching and db caching help reducing the fragmentation. Us'ng redis or memcached for object caching and APC for only opcode caching solves the problem.