3

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.

rowatt
  • 421
  • 4
  • 16

1 Answers1

5

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.

Community
  • 1
  • 1
Serkan Yilmaz
  • 1,338
  • 19
  • 21
  • I only have 1 segment (apc.shm_segments=1) and it is 256M (apc.shm_size=256M). Maybe I am misunderstanding, but as I have never seen more than about 40% of that memory used, how will increasing segment size help? – rowatt Feb 15 '12 at 17:11
  • Which version of APC are you using? – Serkan Yilmaz Feb 16 '12 at 09:25
  • @rowatt did you ever inspected the fragmentation when you set `apc.ttl=0`? Normally some fragmentation in APC is accepted normal but 100% fragmentation is too much. You also use a very big segment. For WP 48 to 64MB of cache size is enough, although big segment can't be the reason for fragmentation. Are there any other VirtualHosts on the same server? I also want to ask if anybody uses WP Admin interface while taking those results? Can you add your full apc.ini to your question? – Serkan Yilmaz Feb 16 '12 at 12:01
  • I've just set apc.ttl=0 and am still seeing fragmentation (8% after a httpd restart 20mins ago). There are 4 other vhosts on the server, they are low traffic but one uses Code Igniter which maybe explains the higher than normal memory requirement. There is little access to wp-admin on this server (and none since the httpd restart). All the user cache entries are from W3TC, and all have TTL of 7200... so I am baffled as to how memory can be getting fragmented after only 20 mins when there is still plenty (>200M) free cache memory! – rowatt Feb 16 '12 at 16:35
  • thanks for the update. I didn't know about using the apc.cache_by_default to turn apc on/off for vhosts, so that's really helpful. I don't see how apc.stat would help fragmentation though... sure if it's set to 0 and a file changes then the cache won't update and that will reduce fragmentation, but if a file has changed then I want it to be updated, no? Either way... setting apc.stat to 0 and turning off APC on all other vhosts hasn't resolved the issue. I am still seeing heavy fragmentation even though there is lots of free cache memory. :-( – rowatt Feb 17 '12 at 10:11
  • @rowatt Can you disable database and object caching and just cache opcode and see the results? – Serkan Yilmaz Feb 17 '12 at 13:59
  • That's a good suggestion! Over the past couple of days I've tried turning off either or both of DB and object caching, and fragmentation is reduced in all cases. A short test with both off resulted in no fragmentation (as expected - since TTL is 0 for opcode), only caching DB resulted in very little fragmentation after a few hours, and after 2 days only 35% fragmentation on object cache. So... seems like W3TC object cache is the main culprit, and having DB cache on makes it much worse. – rowatt Feb 20 '12 at 11:43
  • @rowatt If you want to cache these also, you can use memcached. – Serkan Yilmaz Feb 20 '12 at 12:07