WordPress网站上的APC缓存碎片 [英] APC Cache fragmentation on WordPress site

问题描述

我最近在Web服务器(Centos 5.7，PHP 5.3、1.5Gb RAM)上安装并激活了APC缓存，该服务器主要用于运行W3Total Cache的WordPress站点(访问量为3万唯一访问者/月)，Total Cache设置为使用APC进行数据库和对象缓存(页面，减少使用磁盘).

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).

服务器的APC信息页面显示始终存在大量碎片.例如，重新启动httpd后，碎片在11小时后最多达到75％，而我在几天后看到碎片达到100％.我从来没有见过超过40％的高速缓存使用，并且服务器始终以大约400Mb的内存运行，其中有1100Mb的空闲空间(-/+缓冲区/高速缓存，由free -m报告).因此，似乎没有内存不足会导致碎片.

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.

我从默认的APC和W3TC配置开始，并尝试了以下更改的各种组合:-

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

• apc.ttl从7200减少到1800
• apc.user_ttl设置为0(唯一使用用户缓存的是W3TC，它设置了自己的TTL)
• W3TC超时从180秒增加到7200秒
• apc.filters阻止音调

尽管到目前为止，由Google网站站长工具衡量的主观性能和页面加载时间似乎都没有受到任何影响，但这些变化似乎并没有太大改变.

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?

- 这是完整的apc.ini配置文件:-

- 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:-

这种体验在某些站点上并不意外.我会努力 下一版本中的缓存逻辑可改善APC性能.

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

所以看来W3TotalCache是​​造成碎片的根本原因.

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

推荐答案

尝试增加APC使用的段大小的大小.仅使用一个细分.还可以从您创建的子域访问wp管理界面.

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.

优化APC缓存

如果服务器上还有其他不需要操作码缓存的虚拟主机，则可以为这些站点禁用APC.通过在apc.ini文件中设置apc.cache_by_default=0，并将php_flag apc.cache_by_default On放在wp根目录下的.htaccess文件中，可以在虚拟主机级别上执行此操作.那应该是造成碎片的原因.

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.

文件中的更改也会导致碎片.编辑的文件将被删除，新文件将被添加到缓存中.如果尚未完成，还应该设置apc.stat=0.不必每次都检查文件是否更改，从而提高整体性能.

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.

如果您不希望缓存WP Admin，则可以创建一个子域(如admin.example.com)，并且可以访问管理面板.这样，您将能够禁用操作码缓存.这也将减少碎片.

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.

更新: 禁用对象缓存和数据库缓存有助于减少碎片.使用redis或memcached进行对象缓存，而仅使用APC进行操作码缓存即可解决此问题.

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.

这篇关于WordPress网站上的APC缓存碎片的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！