广泛使用APCu和TYPO3 6.2，随着时间的推移，我总是会得到高速缓存的碎片。我已经使用较小的shm_size获得了99％的值。
如果您是TYPO3管理员，我还将缓存cache_pagesection，cache_hash，cache_pages（目前用于测试目的再次移至DB），cache_rootline， extbase_reflection，extbase_opject以及apc后端的其他扩展缓存。主要是将cache_hash远离DB加速菜单渲染时间（https://forge.typo3.org/issues/57953）
1）APC碎片是否很重要或者我应该注意它永远不会耗尽内存？
2）对于TYPO3管理员：您是否碰巧知道哪些表导致碎片最多，而且apcu.ini配置中的哪些位与TYPO3的使用相关？
我已尝试使用
apc.stat = 0，apc.user_ttl = 0，apc.ttl = 0（如T3缓存指南http://docs.typo3.org/typo3cms/CoreApiReference/CachingFramework/FrontendsBackends/Index.html#caching-backend-apc中所示）并增加shm_size（目前为512M）通常在100M左右的地方使用）。 Shm_size在减少碎片方面做得很好，但我宁愿拥有一个小而完整的缓存而不是一个未使用的缓存。
3）对于APC（u）管理员：是否经常更新大小变化的缓存条目会导致大部分碎片？或者是否有其他我不知道的错误配置？
我知道缓存中有很多条目（主要是来自远程服务器的JSON数据），其中一些条目每5分钟更新一次，通常每次都有不同的大小。如果这确实是一个原因，我该如何避免呢？顺便说一句：APCU信息显示有很多条目只占用2kB，但每个条目的间隔大约为200字节。
4）对于TYPO3和APC管理员：apc在TYPO3中有很好的集成，但是为了更频繁地更新和许多小条目，你会建议不同的缓存后端而不是apc吗？
答案 0 :(得分：0)
这对我们来说已经不再适用了，我找到了一个不同的解决方案，恢复到MySQL缓存。虽然如果有人通过搜索来到这里，这就是我们最终做到的方式：
单独保留APC缓存，仅将其用于预配置的extbase_object缓存。这个小于1MB，在开始时只有少量插入，并且在之后产生非常高的命中/未命中率。如“配置预设”部分中的安装工具中所述，这是缓存后端的设计目标。
我在此过程中发现了此错误https://forge.typo3.org/issues/59587，并再次审核了我们的缓存使用情况。它导致巨大的缓存条目仅用于标记到标识映射。我的结论是，即使在尝试使用固定缓存之后，APCu也非常适合存储频繁访问的键值映射，但在很多频繁插入或标记的条目存在时会产生（例如cache_hash或{{1} }）。
目前，MySQL缓存表在MySQL服务器内存缓存的扩展使用方面具有更好的性能（但与具有磁盘备份的APCu相比）。这是my.cnf的神奇设置（见http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/）：
cache_pages通过这个额外的MySQL服务器设置，默认的typo3缓存表可以最好地完成工作。