我现在有以下几点,我不确定：
>我是否正确地看到碎片发生,因为缓存也被用作用户缓存？
>当我总共分配192MB时,为什么碎片条告诉我100％只有5.8MB？
>这只是一个渲染问题,“内存使用”下的圆圈没有完全关闭？因为下面的MB值确实加起来了. (要说的是,重新启动后圆圈看起来不错,当缓存变得越来越碎片化时,这就变成了这样.)
>由于命中率非常好,我不确定碎片是否是一个大问题.你认为我还能优化吗？
我最感兴趣的是回答这些问题.只有这样,我才能更好地理解APC,并自己做出调整.
一些细节信息：在这台服务器上运行的是Drupal和Magento. Drupal也将它用作用户缓存.
我现在的问题是如何优化它.我可以分配更多内存,但我不确定这是否真的有帮助.
更新：
这是配置：
; The size of each shared memory segment in MB. apc.shm_size = 192M ; Prevent files larger than this value from getting cached. Defaults to 1M. apc.max_file_size = 2M ; The number of seconds a cache entry is allowed to idle in a slot in case ; this cache entry slot is needed by another entry. apc.ttl = 3600
正如你所看到的那样,它目前很少.
Do I see it correctly that the fragmentation happens because the cache
is used as an user cache too?
不,当文件的操作码缓存大小发生变化时会发生碎片,并且它不适合它之前占用的“切片” – 在引擎盖下它有点复杂,但这就是要点.
Why does the fragmentation bar tell me 100% of only 5.8MB when I
allocated 192MB in total?
它告诉你100％,因为在你的免费可用缓存空间中,100％的碎片涉及碎片(意味着该’切片’的进入障碍必须落入碎片大小).
Is this just a rendering problem that the circle under “Memory Usage” is not fully
closed?
是的,不要相信它; “切片内”打印的值有时也不正确.
Since the hit rate is really good I am not sure if the fragmentation
is a big problem or not. Do you think that I can still optimize it?
绝对！我会增加缓存.您可以分配100MB,缓存10MB,并且仍然具有100％的命中率.
一个成功的设置应该很少修剪(AKA：很少到没有gc) – 和肘部空间扩展,你想要一点额外的空间; (超过5MB)因为碎片的影响会使想要进入缓存的事情“复杂化”.
拍摄10％免费,非碎片空间,继续监控并增加尺寸.还要知道,推送大量新代码文件也会对缓存产生影响.