我最近在一台网络服务器(Centos 5.7,PHP 5.3,1.5GB RAM)上安装并启用了APC缓存。该服务器主要用于中等流量(每月30,000个独立访客)的WordPress网站,运行W3Total Cache,并设置使用APC进行数据库和对象缓存(页面、缩小使用磁盘)。
服务器的APC信息页面显示存在持续的重度碎片。例如,在重新启动 httpd 后,碎片率在11小时后达到了75%,我曾经看到过它在几天后达到了100%。任何时候,我都从未见过超过约40%的缓存内存被使用,而且服务器始终以大约400MB的内存使用、1100MB的空闲空间运行(-/+ 缓冲/缓存,由free -m报告)。因此,似乎不是缺少内存导致了碎片化。
我从默认的APC和W3TC配置开始,并尝试了以下更改的各种组合:
- apc.ttl 从7200降低到1800 - apc.user_ttl 设置为0(唯一使用用户缓存的是W3TC,它会设置自己的TTL) - 将W3TC超时时间从180秒增加到7200秒 - 使用apc.filters阻止timthumb
这些更改似乎没有什么区别,尽管到目前为止,通过Google网站管理员工具测量的主观性能和页面加载时间似乎都没有受到影响。
我应该担心吗?虽然当前的表现似乎没有问题,但我宁愿在服务器负载/站点流量上升之前解决这个问题。如果确实存在问题,我可以采取什么步骤来解决?
编辑: 以下是完整的apc.ini配置文件:
服务器的APC信息页面显示存在持续的重度碎片。例如,在重新启动 httpd 后,碎片率在11小时后达到了75%,我曾经看到过它在几天后达到了100%。任何时候,我都从未见过超过约40%的缓存内存被使用,而且服务器始终以大约400MB的内存使用、1100MB的空闲空间运行(-/+ 缓冲/缓存,由free -m报告)。因此,似乎不是缺少内存导致了碎片化。
我从默认的APC和W3TC配置开始,并尝试了以下更改的各种组合:
- apc.ttl 从7200降低到1800 - apc.user_ttl 设置为0(唯一使用用户缓存的是W3TC,它会设置自己的TTL) - 将W3TC超时时间从180秒增加到7200秒 - 使用apc.filters阻止timthumb
这些更改似乎没有什么区别,尽管到目前为止,通过Google网站管理员工具测量的主观性能和页面加载时间似乎都没有受到影响。
我应该担心吗?虽然当前的表现似乎没有问题,但我宁愿在服务器负载/站点流量上升之前解决这个问题。如果确实存在问题,我可以采取什么步骤来解决?
编辑: 以下是完整的apc.ini配置文件:
; 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
更新:我还在WP论坛上发布了帖子,并从W3TotalCache的作者那里得到了这个回复:
在某些站点上,这种情况是可以预料的。在下一个版本中,我将致力于改进缓存逻辑,以提高APC的性能。
因此,看起来W3TotalCache是碎片化的根本原因。
apc.ttl=0
时,您是否检查过APC的碎片化情况?通常APC中的一些碎片化是可以接受的,但100%的碎片化太多了。您还使用了非常大的段。对于WP来说,48到64MB的缓存大小足够了,尽管大段不能成为碎片化的原因。在同一台服务器上是否有其他虚拟主机?我还想问是否有人在使用WP管理界面时获取这些结果?您能否将完整的apc.ini添加到您的问题中? - Serkan Yilmaz