AWS EC2小实例，运行WordPress和W3TC的Apache 2。 不到一个小时，我的APC碎片就达到了100％。
我的APC设置是：
apc.enabled = 1 apc.shm_segments = 1 apc.shm_size = 100M apc.optimization = 0 apc.num_files_hint = 512 apc.user_entries_hint = 1024 apc.ttl = 7200 apc.user_ttl = 7200 apc.gc_ttl = 3600 apc.cache_by_default = 1 apc.use_request_time = 1 apc.filters = "apc\.php$" apc.mmap_file_mask = "/tmp/apc.XXXXXX" apc.slam_defense = 0 apc.file_update_protection = 2 apc.enable_cli = 0 apc.max_file_size = 2M apc.stat = 1 apc.write_lock = 1 apc.report_autofilter = 0 apc.include_once_override = 0 apc.rfc1867 = 0 apc.rfc1867_prefix = "upload_" apc.rfc1867_name = "APC_UPLOAD_PROGRESS" apc.rfc1867_freq = 0 apc.localcache = 0 apc.localcache.size = 256M apc.coredump_unmap = 0 apc.stat_ctime = 0 apc.canonicalize = 1 apc.lazy_functions = 0 apc.lazy_classes = 0 /etc/php.d/apc.ini 更多的便便可以在这里看到 。
主要是从这里扣留设置。 经过一番观察，shm本来就是从这么高的价值中减less的，但显然这样一个大的价值还不够高。
我在这里find了类似的问题/答案。 我确实有一些虚拟主机设置，但他们没有被感动得太多。 让用户login到WP的pipe理面板确实让事情变得更糟，但这当然不是主要的罪魁祸首。 问题提供者似乎表明，事实certificate， W3TC可能导致了这个插件作者似乎同意的问题，但除此之外没有任何有用的细节。 为什么会造成这个问题？
我现在只是拿它，closures与APC的对象caching？ 我能做什么吗？ 打开它而不用于对象caching实际上有助于任何事情吗？ memcache是一个好的替代品，只是为了caching对象吗？ 最后，也许我不应该为这些碎片担心太多。
Cached variables: 3562 ( 14.3 MBytes)
这是什么导致你的碎片。 GC正在清理它们，当它们被再生时，它们有可能被置于一个新的“切片”中。
您可以尝试在用户variables上启用GC TTL，但是如果您的APC使用的代码是手动处理可能成为问题一部分的TTL。
3500+的variables对于我所看到的是相当多的（只有500个文件被caching，100MB SHM）; APC可能无法正确使用。
编辑：
Hits 19195 Misses 13830
Insert Rate 1312.99 cache requests/second < – 这让我觉得有些东西configuration不正确。 从技术上讲，这是告诉我，你的caching大部分是无效的，因为你的cachingvariables的33％是每秒产生的。