我已经玩了很长一段时间,但是我有点不知所措.我在使用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)递增.
在撰写本文时,尽管APC报告280MB免费,我的UCCFC仍在62358并且还在增长.我有一个7200的user_ttl,但我也玩过它设置为0或其他数量,它对问题几乎没有影响.
我怀疑这个问题与碎片有关.现在我的服务器正在报告"碎片:100.00%(24740片段中280.0 MBy中280.0 MB)"和280 MB正好恰好是APC报告的可用空间量; 我想,这是个巧合.不幸的是,我在文档或其他地方发现了很少的信息来表明APC世界中"碎片化"真正意味着什么,而且似乎几乎没有任何东西可以避免它.
任何人都能解释这个问题吗？
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 配置设置发生以下两种情况之一.如果TTL设置为0,则刷新整个用户缓存并插入项目.如果TTL设置为大于0,则它将刷新过期的条目并插入该项目.在这两种情况下,缓存完整计数都会增加.在你的情况下尽可能多地增加这个增量表明你可能做错了.
这是一个简单的可视化,显示碎片对缓存的影响.它表示一个简单的32字节高速缓存大小,每个块为1B.
[--------------------------------] (starts empty) [A-------------------------------] (1B stored) [ABB-----------------------------] (2B stored) [ABBCCCC-------------------------] (4B stored) ... (time elapses) [A--CCCC-EEE--GGGGGG-III--KKKLLLL]
所以现在如果要存储M大小为4B的项目,则不能,因为最大的可用块是2B.这将触发缓存完全计数增量,以及基于上面详细解释的user_ttl的完全或部分刷新.
现在的问题是:你的情况是不是很糟糕？
我想可能是这样.100%的缓存碎片本身并不坏.在任何正在运行的生产服务器上看到这种情况并不罕见.然而,在看到它的100%,这多少可用空间是不是有什么事情是错误的标志.
你可能会过多地缓存; 仅仅因为缓存并不意味着你应该把所有东西都塞进去.
你可能会用太短的TTL缓存(对于一个条目),低TTL意味着非自由块被更频繁地释放.
您可能还有一些非常大的物品需要存放.在100%碎片时,保证任何≥5M的项目都不合适.随着你的平均自由区块大小为11.6K,随着它的大小增加超过11.6K,一个给定的项目越来越不适合.
您可能希望尝试按大小对用户缓存进行排序,并查看最大的条目以及它们的TTL.也许他们可以增加？
如果不在您的应用程序和使用模式中进行深入研究,就不可能给出准确的诊断,但所有这些信息都应该让您走在正确的轨道上.这很可能是一个非问题,你可以让APC悄悄地做它的工作.
京公网安备 11010802040832号 | 京ICP备19059560号-6 