带有 TYPO3 的 APC：随着时间的推移高度碎片化

Question

广泛使用带有 TYPO3 6.2 的 APCu，随着时间的推移，我总是会得到很高的缓存碎片。我已经有了 99% 的值，而 shm_size 更小。

如果您是 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 Info 显示有很多条目仅占用 2kB，但每个条目的碎片间距约为 200 字节。

4) 致 TYPO3 和 APC 管理员：apc 在 TYPO3 中有很好的集成，但是对于更频繁的更新和许多小条目，您是否建议使用与 apc 不同的缓存后端？

Answer 1

这与我们不再相关，我发现了一个不同的解决方案，恢复到 MySQL 缓存。虽然如果有人通过搜索来到这里，我们最终就是这样做的：

保留 APC 缓存，仅将其用于预配置的 extbase_object 缓存。这个小于 1MB，在开始时只有少量插入，之后会产生非常高的命中/未命中率。正如“配置预设”部分的安装工具中所述，这就是缓存后端的设计目的。

我在此过程中发现了这个错误https://forge.typo3.org/issues/59587，并再次检查了我们的缓存使用情况。它导致巨大的缓存条目仅用于标签到标识的映射。我的结论是，即使在尝试了固定缓存之后，APCu 也非常适合存储经常访问的键值映射，但是当周围有很多经常插入或标记的条目时（例如 cache_hash 或 cache_pages）就会产生。

目前，MySQL 缓存表在 MySQL 服务器内存缓存的扩展使用情况下具有更好的性能（但与使用磁盘备份的 APCu 相比）。这是我们的 my.cnf 的神奇设置（可在此处找到：http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/）：

innodb_buffer_pool_size = 512M
innodb_log_file_size = 256M
innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 2
innodb_thread_concurrency = 8
innodb_flush_method=O_DIRECT
innodb_file_per_table

通过这个额外的 MySQL 服务器设置，默认的typo3 缓存表可以发挥最佳作用。