我可以优化这些APC设置吗？

我是否正确地看到碎片发生，因为caching也被用作用户caching？

不，当一个文件的操作码高速caching大小发生变化时，可能会发生碎片化，而且不能适应之前占用的“分片”，但是这样做有点复杂，但这是要点。

为什么当我总共分配192MB时，碎片条只能告诉我只有5.8MB的100％？

它告诉你100％，因为你的免费，可用的caching空间，其中100％涉及到碎片（这意味着“切片”的进入壁垒必须落入碎片大小）。

这只是一个渲染问题，“内存使用情况”下的圆圈没有完全closures？

是的，不要相信它; 在“切片内”打印的值也是不正确的。

由于命中率真的很好，我不确定是否碎片是一个大问题。 你认为我还可以优化吗？

绝对！ 我会增加caching。 你可以有一个100MB的分配，并有10MB的caching，仍然有100％的命中率。

一个成功的设置应该有一点修剪（又名：几乎没有gc）和肘扩展的空间，你想要一点额外的空间; （大于5MB），因为碎片效应会使想要进入caching的东西“复杂化”。

拍摄10％免费，非零碎的空间，继续监测和增加尺寸。 也知道推送大量的新代码文件也会对caching产生影响。

关于问题3，
我不能完全告诉你为什么这个圆圈没有完全closures，但是对于我的设置，在几天的正常运行时间以及10％的碎片之后，它看起来是一样的。

2，
我认为这是APC统计页面中的一个小故障，我告诉我“10.34％（从89个碎片中的7.3 MB到771.7 KB）”，根据内存使用统计，7.3 MB内存应该是免费的。
如果你看看你的截图，你会发现它看起来像是在做同样的事情
5.8中的5.8是零碎的，5.8是免费的，所以无论是在计算空闲内存上的碎片，还是数字都是错误的。

看我的屏幕比较：

你应该看一下“Cache full count”计数器，> 1表示你用完了APC的内存，在这种情况下你在3天内用完了39次，这似乎很多。

看起来，使用用户caching比使用PHP文件caching导致这种碎片更有可能，因为它倾向于caching许多小的不同对象，最终占用内存只是为了引用它们的存在。

我要做的第一件事就是尝试启动分配的APC内存（安全地，2Go不应该是解决scheme），直到“caching完全计数”不再发生，那么我将专注于用户caching中推送的对象的数量。
如果你可以限制它们的数量（而不是它们的大小），那么它会很棒，但是你可以探索不同的可能性，比如memcache来存储那个用户caching，并且把APC专用于文件caching。

发布你当前的APCconfiguration将有很大的帮助，因为我们可以看看在这种情况下可能很重要的TTL值。