Redis支持3种内存分配器：libc，jemalloc，tcmalloc。当我进行内存使用率测试时，我发现使用libc分配器的INFO MEMORY中的mem_fragmentation_ratio可能小于1。对于jemalloc或tcmalloc，此值应大于或等于1。
有人可以解释为什么mem_fragmentation_ratio在libc中小于1吗？
Redis版本：2.6.12。 CentOS 6
更新：
我忘记提及一个可能的原因是发生交换，并且mem_fragmentation_ratio将为<1。
但是当我进行测试时，我会调整互换性，甚至关闭互换。结果是一样的。而且我的redis实例实际上不需要花费太多内存。
通常，与libc malloc相比，jemalloc或tcmalloc的碎片更少。这是由于四个因素：
jemalloc和tcmalloc的更多粒度分配类。它减少了内部碎片，特别是当Redis必须分配很多非常小的对象时。
更好的算法和数据结构可以防止外部碎片（特别是对于jemalloc）。显然，增益取决于您的长期内存分配模式。
支持“ malloc大小”。一些分配器提供了一个API，以返回分配的内存大小。使用glibc（Linux），malloc不具有此功能，因此可以通过在每个分配的内存块中显式添加一个额外的前缀来进行仿真。它增加了内部碎片。使用jemalloc和tcmalloc（或使用BSD libc malloc）时，没有这样的方法开销。
jemalloc（和带有某些设置更改的tcmalloc）可以比glibc更积极地向操作系统释放内存-但同样，这取决于分配模式。
现在，如何获得mem_fragmentation_ratio的不一致值？
如the INFO documentation中所述，mem_fragmentation_ratio值计算为进程的内存驻留集大小（RSS，由OS衡量）与Redis使用分配器分配的字节总数之比。
现在，如果通过libc分配了更多的内存（与jemalloc，tcmalloc相比），或者在基准测试期间系统上的其他进程使用了更多的内存，则Redis内存可能会被OS换出。它将减少RSS（因为Redis内存的一部分不再在主内存中）。产生的碎片比率将小于1。
换句话说，只有当您确定操作系统没有更换Redis内存时，此比率才有意义（如果不是，则仍然会出现性能问题。）>]
除了交换以外，我知道使“内存碎片比率”小于1的2种方法：