为什么Redis碎片率（mem_fragmentation_ratio） 大于 1小于1.5才合理？
Redis内存分配的策略中，内存分配器一般是按照固定大小来分配内存，而不是完全按照Redis实例申请的内存空间大小给程序分配，所以每一次分配都会产生剩余空间，这里是Redis内存碎片。
随着系统的运行，这些零散的，不连续的空间逐步积累越来越多，所以碎片量也越来越大。
碎片率计算公式：
mem_fragmentation_ratio（碎片率） = used_memory_rss/ used_memory
used_memory ：Redis的分配内存大小
used_memory_rss ：Redis实例进程所占物理内存的大小
注：mem_fragmentation_ratio（碎片率）健康状态应该大于1。
打一个形象一点的比喻，毕竟不是每个人都是大神。
操作系统是老板，分配器是主管，Redis是主管下边的一个工程师。为了鼓励工程师加班加点地卖命干活，老板放血了搞了点夜宵给补助1000元（相当于used_memory 1000M内存）。
主管为了最好地利用这1000元来激励Redis卖命干活，实现人生价值，1000元不一次给完，分次给redis，这样好控制redis加班次数。Redis每次领100元，再发票实报实销，Redis领钱90.50－99.9元间不等。每次都可能有尾数，便成了内存碎片钱。
mem_fragmentation_ratio（消费率）小于1时，表示主管当月总给了1000元，Redis工程师实际上花费了1200元，还有200元是另掏腰包的，相当于动用了虚内存(swap)200M，相当于损失了自己的财富，降低了性能。
mem_fragmentation_ratio（消费率）大于1时，表示分给了Redis的1000元，Redis当月实际只吃了970元，消费率1.3＝1000/970。按米下锅，有计划地过日子是一种品质。所以说，碎片率大于1时是一种健康状态。
报多了自己多花钱，报得太少自己又亏。Redis算得很精确，吃上970元又不超过1000元，零头只剩余30元。这样一来，Redis得到了实在，又给了主管面子，太精准刚刚报1000元，主管会觉得你太算计这1000元了。所以说，mem_fragmentation_ratio（碎片率）大约1.3时，Redis处于一种健康状态。
mem_fragmentation_ratio（碎片率）大于1.5时，表示Redis只吃了666元，1.6=1000/666。那么辛苦，剩余333元没有报销，那就有点傻B了。本来1000元就是血汗钱，鼓励做工来的。
所以，Redis决定：接近月底时，还有333元没报销的话，这就有点多了，营养和卡路里（calorie）肯定跟不上来，工作效率自然会降低，毕竟人是铁饭钢。于是Redis在部门不太忙，主管心情好的时候，赶紧把剩余的碎片钱报销完了。这便成了碎片整理机制。
什么时候报销碎片钱呢，这是有时间点和次数讲究的。主管(CPU)太忙，花费处理时间（大于75%）时不要去报销。次数也不要太多，不要花主管(CPU)太少时间（小于25%）也不要去报销。毕竟每次报销，主管主管(CPU)都要一张一张地核查发票，也很费时间，降低部门工作效率。这相当于内存碎片整理的条件。
故事毕竟是故事，还是说说整理内存碎片的一些措施。
一个简单粗暴的方法就是重启 Redis 实例，一次性清空。不过，重启 Redis 会带来两个不良后果：如果 Redis 中的数据没有持久化，那么，缓存数据就会丢失。其次是即使 Redis 数据已经持久化了，通过 AOF 或 RDB 进行恢复同样需要时间，恢复阶段无法提供缓存服务，这时碰到大流量的话，服务器就无法承受。另一种方法就是开启碎片回收机制，有计划地整理碎片。
所以，最佳的Redis碎片整理要有节奏性，并且把Redis碎片率（mem_fragmentation_ratio） 控制在 1到1.5之间，比如1.25左右。
随着系统的运行，这些零散的，不连续的空间逐步积累越来越多，所以碎片量也越来越大。
碎片率计算公式：
mem_fragmentation_ratio（碎片率） = used_memory_rss/ used_memory
used_memory ：Redis的分配内存大小
used_memory_rss ：Redis实例进程所占物理内存的大小
注：mem_fragmentation_ratio（碎片率）健康状态应该大于1。
打一个形象一点的比喻，毕竟不是每个人都是大神。
操作系统是老板，分配器是主管，Redis是主管下边的一个工程师。为了鼓励工程师加班加点地卖命干活，老板放血了搞了点夜宵给补助1000元（相当于used_memory 1000M内存）。
主管为了最好地利用这1000元来激励Redis卖命干活，实现人生价值，1000元不一次给完，分次给redis，这样好控制redis加班次数。Redis每次领100元，再发票实报实销，Redis领钱90.50－99.9元间不等。每次都可能有尾数，便成了内存碎片钱。
mem_fragmentation_ratio（消费率）小于1时，表示主管当月总给了1000元，Redis工程师实际上花费了1200元，还有200元是另掏腰包的，相当于动用了虚内存(swap)200M，相当于损失了自己的财富，降低了性能。
mem_fragmentation_ratio（消费率）大于1时，表示分给了Redis的1000元，Redis当月实际只吃了970元，消费率1.3＝1000/970。按米下锅，有计划地过日子是一种品质。所以说，碎片率大于1时是一种健康状态。
报多了自己多花钱，报得太少自己又亏。Redis算得很精确，吃上970元又不超过1000元，零头只剩余30元。这样一来，Redis得到了实在，又给了主管面子，太精准刚刚报1000元，主管会觉得你太算计这1000元了。所以说，mem_fragmentation_ratio（碎片率）大约1.3时，Redis处于一种健康状态。
mem_fragmentation_ratio（碎片率）大于1.5时，表示Redis只吃了666元，1.6=1000/666。那么辛苦，剩余333元没有报销，那就有点傻B了。本来1000元就是血汗钱，鼓励做工来的。
所以，Redis决定：接近月底时，还有333元没报销的话，这就有点多了，营养和卡路里（calorie）肯定跟不上来，工作效率自然会降低，毕竟人是铁饭钢。于是Redis在部门不太忙，主管心情好的时候，赶紧把剩余的碎片钱报销完了。这便成了碎片整理机制。
什么时候报销碎片钱呢，这是有时间点和次数讲究的。主管(CPU)太忙，花费处理时间（大于75%）时不要去报销。次数也不要太多，不要花主管(CPU)太少时间（小于25%）也不要去报销。毕竟每次报销，主管主管(CPU)都要一张一张地核查发票，也很费时间，降低部门工作效率。这相当于内存碎片整理的条件。
故事毕竟是故事，还是说说整理内存碎片的一些措施。
一个简单粗暴的方法就是重启 Redis 实例，一次性清空。不过，重启 Redis 会带来两个不良后果：如果 Redis 中的数据没有持久化，那么，缓存数据就会丢失。其次是即使 Redis 数据已经持久化了，通过 AOF 或 RDB 进行恢复同样需要时间，恢复阶段无法提供缓存服务，这时碰到大流量的话，服务器就无法承受。另一种方法就是开启碎片回收机制，有计划地整理碎片。
所以，最佳的Redis碎片整理要有节奏性，并且把Redis碎片率（mem_fragmentation_ratio） 控制在 1到1.5之间，比如1.25左右。
精选留言