AWS EC2 小型实例，Apache 2 运行 WordPress 和 W3TC。一小时内，我的 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 本来应该从如此高的值逐渐减少，但显然这么大的值还不够高……
我找到了类似的问题/答案这里。我确实设置了一些虚拟主机，但它们并没有受到太大的影响。让用户登录 WP 的管理面板确实会让事情变得更糟，但这肯定不是罪魁祸首。提问者似乎暗示，事实证明W3TC 可能是造成该问题的原因，插件作者似乎同意这一点，但除此之外没有任何有用的细节。为什么它会导致问题？
我是不是只能暂时关闭 APC 的对象缓存？难道我就无能为力了？打开它而不用于对象缓存真的有帮助吗？memcache 是否可以作为对象缓存的替代品？最后，也许我不应该太担心碎片化问题？
答案1
Cached variables: 3562 ( 14.3 MBytes)
这就是造成碎片的原因。GC 正在清理它们，并且很有可能在它们重新生成时被放置在新的“切片”中。
您可以尝试提高用户变量的 GC TTL - 但如果您使用 APC 的代码手动处理 TTL，则这可能是问题的一部分。
就我所见，3500+ 个变量相当多（仅缓存了 500 个文件，100MB SHM）；APC 可能无法正确利用。
编辑：
Hits 19195
Misses 13830
Insert Rate 1312.99 cache requests/second<-- 这让我觉得有些配置不正确。从技术上讲，这告诉我您的缓存基本上是无效的，因为每秒都会生成 33% 的缓存变量。