我已经玩了很长一段时间了，但是对于做什么感到有些不知所措。我在使用PHP 5.2.5的CentOs 5上使用APC 3.1.3p1。 APC充当操作码缓存和用户缓存。大多数情况下，此服务器使用CacheRouter模块运行Drupal 6站点以支持APC缓存。我正在运行APC 3.0.19一段时间，但它导致Apache偶尔锁定（在该版本的APC中记录的错误），这就是我在3.1.3p1上的原因。
我已将APC配置为512 MB内存（mmap）。
症状有点间歇性但从空缓存开始这通常是我所看到的：
用户缓存填充速度相当慢。尽管初始插入速率大约为20,000次插入/秒，但用户缓存只会报告几百个，然后是几千个条目，并且增长速度非常慢。我可以将此归因于write_locking正在进行，但只是想提及它，以防它在解决手头的问题时非常重要。几个小时后，它达到约30,000个条目的平衡。
碎片设置尽早并且快速增长。大约10个小时左右，我通常会100％碎片化。
整体（操作码+用户）缓存使用量稳定在240MB左右。它实际上永远不会超过这个水平。大约一天后，我将开始看到用户缓存高速缓存满计数（UCCFC）递增。
在撰写本文时，我的UCCFC处于62358，尽管APC报告280MB免费，但仍在增长。我有一个7200的user_ttl，但我也把它设置为0或其他数量，它对问题几乎没有影响。
我怀疑这个问题与碎片有关。现在我的服务器正在报告“碎片：100.00％（24740片段中280.0 MBy中280.0 MB）”和280 MB正好恰好是APC报告的可用空间量;我想，这是个巧合。不幸的是，我在文档或其他地方发现了很少的信息来表明APC世界中“碎片化”究竟意味着什么，而且似乎没有什么可以做的，以避免它。
任何人都可以解释这个问题吗？
答案 0 :(得分：22)
APC使用以下公式计算碎片百分比：
(total_size_of_free_blocks_lt_5M / total_size_of_all_free_blocks) * 100
* 请注意，它只将小于5M的块计为碎片。
我会将您的具体案例翻译成普通英语：
碎片：100.00％（24740碎片中280.0 MBytes中280.0 MB）
这意味着280M的空闲块所有中的小于5M。如果您将可用空间除以片段数，您将看到这相当于平均片段大小~11.6K。
这意味着如果您尝试存储的项目大于所有可用的块，则它将不适合，并且基于apc.user_ttl configuration setting将发生以下两种情况之一。如果TTL设置为0，则刷新整个用户缓存并插入项目。如果TTL设置为大于0，则它将刷新过期的条目并插入该项目。在这两种情况下，缓存完整计数都会增加。在您的情况下尽可能多地增加此增量表明您可能是doing it wrong。
这是一个简单的可视化，显示碎片对缓存的影响。它表示一个简单的32字节高速缓存大小，每个块为1B。
[--------------------------------] (starts empty) [A-------------------------------] (1B stored) [ABB-----------------------------] (2B stored) [ABBCCCC-------------------------] (4B stored) ... (time elapses) [A--CCCC-EEE--GGGGGG-III--KKKLLLL]
所以现在如果要存储大小为4B的项目M，则不能，因为最大的可用块是2B。这会触发缓存完全计数增量，以及基于上面详细解释的user_ttl的完全或部分刷新。
现在的问题是：你的情况是不是很糟糕？
我认为可能是。 100％的缓存碎片本身并不坏。在任何正在运行的生产服务器上看到这种情况并不罕见。但是，要通过 来查看它是100％，这意味着可能出现问题。
您可能希望尝试按大小对用户缓存进行排序，并查看最大的条目以及它们的TTL。也许他们可以增加？
如果没有在您的应用程序和使用模式中深入肘部，确实无法给出确切的诊断，但所有这些信息都应该让您走在正确的轨道上。这很可能是一个非问题，你可以让APC悄悄地做它的工作。
答案 1 :(得分：0)
http://pecl.php.net/bugs/bug.php?id=13146我认为你应该继续那里或者开一个新的错误报告。
