【问题标题】:Why is APC incrementing "Cache full count" for User Cache even though it has plenty of memory available?为什么 APC 会增加用户缓存的“缓存满计数”,即使它有足够的可用内存?
【发布时间】:2010-07-28 14:50:45
【问题描述】:

我已经玩了很长时间了,但我不知道该怎么做。我在 CentOs 5 上使用 APC 3.1.3p1 和 PHP 5.2.5。 APC 同时充当操作码缓存和用户缓存。大多数情况下,该服务器使用 CacheRouter 模块运行 Drupal 6 站点以支持 APC 缓存。我运行 APC 3.0.19 有一段时间了,但它导致 Apache 偶尔锁定(该版本 APC 中有一个记录在案的错误),所以这就是我使用 3.1.3p1 的原因。

我已将 APC 配置为具有 512 MB 的内存 (mmap)。

症状有点间歇性,但从空缓存开始,这通常是我所看到的:

  • 用户缓存的填充速度相当慢。尽管初始插入速率约为 20,000 次插入/秒,但用户缓存只会报告几百个,然后是几千个条目,并且增长非常缓慢。我可以将其归因于 write_locking 正在打开,但只是想提一下,以防它对解决手头的问题很重要。几个小时后,它达到了大约 30k 个条目的平衡。

  • 碎片化很早就开始并迅速发展。在大约 10 小时左右的时间里,我通常会处于 100% 的碎片化状态。

  • 总体(操作码 + 用户)缓存使用量稳定在 240MB 左右。它几乎永远不会超过这个水平。大约一天后,我将开始看到用户缓存缓存满计数 (UCCFC) 增加。

在撰写本文时,我的 UCCFC 为 62358,并且还在增长,尽管 APC 报告有 280MB 可用空间。我有一个 7200 的 user_ttl,但我也尝试将其设置为 0 或其他数量,它对问题几乎没有影响。

我怀疑这个问题与碎片有关。现在我的服务器正在报告“碎片:100.00%(24740 个碎片中的 280.0 MB 中的 280.0 MB)”,而 280 MB 恰好是 APC 报告的可用空间量;我认为这是一个巧合。不幸的是,我在文档或其他地方发现了很少的信息来说明“碎片化”在 APC 世界中的真正含义,而且您似乎几乎无法避免它。

谁能解释一下这个问题?

【问题讨论】:

  • 您是否尝试过增加共享内存的数量?
  • 感谢您的回复。尽管我从未将其设置为超过 512MB,但我已经多次使用这些设置。有趣的是,当我将其配置为 256MB 时,内存使用量通常在 220MB 范围内,剩余大约 30MB 可用。但是,与配置为 512MB 时相比,我的缓存完整计数通常开始增加得更快,即使原始内存使用情况非常相似。

标签: php drupal caching apc


【解决方案1】:

APC 使用以下公式计算碎片百分比:

(total_size_of_free_blocks_lt_5M / total_size_of_all_free_blocks) * 100

*注意,它只将小于 5M 的块计为碎片。

我会将您的具体案例翻译成简单的英文:

分片:100.00%(280.0 MB,280.0 MB,24740 个分片)

这意味着您的 280M 空闲块中所有都小于 5M。如果您将可用空间除以片段数,您会发现这相当于平均片段大小约为 11.6K。

这意味着如果您尝试存储大于所有可用块的项目,它将不适合,并且会发生两种情况之一,基于apc.user_ttlconfiguration setting。如果 TTL 设置为 0,则刷新整个用户缓存并插入项目。如果 TTL 设置为大于 0,那么它将刷新过期条目并插入项目。在这两种情况下,缓存满计数都会增加。与您的情况一样多的增量表明您可能是doing it wrong

以下是碎片随时间对缓存造成的影响的简单可视化。它表示一个简单的 32 Byte 缓存大小,每个块为 1B。

[--------------------------------](开始为空) [A-------------------------------------------] (1B 已存储) [ABB--------------](2B存储) [ABBCCCC-------------](4B存储) ...(时间流逝) [A--CCCC-EEE--GGGGGG-III--KKKLLLL]

所以现在如果你想存储大小为 4B 的项目 M,你不能,因为最大的可用块是 2B。这会触发缓存完整计数增量,以及基于上面详细解释的 user_ttl 的全部或部分刷新。

现在的问题是:这对你来说很糟糕吗?

我想可能是这样。 100% 的缓存碎片本身并不坏。在任何运行的生产服务器上看到这种情况并不少见。但是,如果看到它在 100% 的情况下 有很多可用空间,则表明可能有问题。

  • 您可能缓存过多;仅仅因为缓存在那里并不意味着您应该将所有东西推入其中。
  • 您可能缓存的 TTL 太短(对于条目),低 TTL 意味着非空闲块被更频繁地释放。
  • 也有可能您要存储一些非常大的物品。在 100% 碎片化的情况下,可以保证任何 >= 5M 的项目都不适合。由于您的平均可用块大小为 11.6K,随着它的大小增加到超过 11.6K,给定项目不适合的可能性越来越大。

您可能想尝试按大小对用户缓存进行排序,并查看最大的条目是什么,以及它们的 TTL 是多少。也许他们可以增加?

如果不深入了解您的应用程序和使用模式,实际上不可能给出准确的诊断,但所有这些信息都应该让您走上正确的道路。这很可能不是问题,您可以让 APC 安静地完成它的工作。

【讨论】:

  • 我只是想跟进。我们迁移到 APC 3.1.4,它的碎片性能得到了极大的改善。我们现在的行为更加符合我们的预期。
【解决方案2】:

http://pecl.php.net/bugs/bug.php?id=13146我认为你应该继续那里或打开一个新的错误报告。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-07-27
    • 2011-12-18
    • 1970-01-01
    • 2019-10-23
    • 1970-01-01
    • 2013-06-09
    相关资源
    最近更新 更多