原文:http://mengzhuo.org/blog/linux%E4%B8%8Bredis%E5%86%85%E5%AD%98%E4%BC%98%E5%8C%96.html 最近使用Redis,由于它属于内存数据库,所以调优都集中到了内存上。 根据Redis官方说法: 需要将 vm.overcommit 设置为1 sysctl vm.overcommit_memory=1 确保

原文:http://mengzhuo.org/blog/linux%E4%B8%8Bredis%E5%86%85%E5%AD%98%E4%BC%98%E5%8C%96.html

最近使用Redis,由于它属于内存数据库,所以调优都集中到了内存上。

根据Redis官方说法:

  • 需要将vm.overcommit设置为1
    sysctl vm.overcommit_memory=1
    登录后复制
  • 确保设置了一定量的swap,最好和内存一样大,否则内核的OOM(out-of-memory)killer会干掉Redis进程
  • 若Redis是大量写入的应用,持久化的RDB或者AOF会按比例使用,或很有可能使用redis使用量的一样多的内存.

Linux下Redis内存优化-LMLPHP
使用和Redis一样多的内存做持久化,那我岂不是都得让一半的内存出来给它?
还有那个overcommit是几个意思也不解释一样?搞砸了其他进程肿么办?

好吧,得研究一下内存是如何管理的:
内核会将物理内存分割成动态虚拟的内存页(page),然后在malloc时按overcommit_memory和overcommit_ratio的设置来确定是否允许分配虚拟内存页。
翻看Linux Kernel的文档/资料才发现,有三种值:

  • overcommit_memory=0,默认,智能超发,每次要求分配内存时,kernel都会比较请求的空间和空余的空间是否足以分配
  • overcommit_memory=1,请求分配内存时,永远假装还有足够的内存
  • overcommit_memory=2,不允许超发内存,即允许分配的大小小于

好吧,Redis要大家假装还有空余内存…也就是说会有很大的几率触发Swap造成性能急剧下降,不过,性能下降总比不能用好

说到swap,大家肯定给Redis服务器设定过swappiness=0,然后祈祷奇迹的发生,但是还是触发了swap。
为什么呢?

首先,Linux十分注重读写性能,尽量避免磁盘IO,你从磁盘上读取的文件会被放入内存,就算程序结束了,还是存在的,这部分内存被称为file buffer(或者file page),是swap重点照顾的回收对象。
其次,Linux上的用户态进程所有页(也就是redis运行时占用的)也是可以回收的。

其实,swap的触发机制是这样的:

根据swap倾向(swap_tendency)决定回收用户态页还是file buffer,最后把LRU队列中用得最少的放入swap空间中。

摘自LWN
以下是内核计算其 “swap倾向”的公式:

swap_tendency = mapped_ratio/2 + distress + vm_swappiness
登录后复制

其中:

  • distress 值是内核在释放内存时遇到的问题数。当内核第一次决定收回内存页面时, distress将为0;尝试次数越多,这个值也越大。
  • mapped_ratio值是mapped page与总page比例,即
    mapped ratio = (nr mapped * 100) / total memory
    登录后复制

    nr_mapped可以从下面的命令行获得

    grep nr_mapped /proc/vmstat
    登录后复制
  • vm_swappiness 就是大家设定的swappniness值

当swap_tendency超过100时,swap就开始收集最近较少用的页。
而且swappiness设置为0,PRFA就不会回收用户态页,
设置为100时,总是回收用户态页,当然这不是我们想看到的。

最后回到之前的问题,怎么避免触发swap?
其实调整好swapiness之后,只需要监测/proc/zoneinfo中的pages free/high 之间的差值即可,high是当前zone中计算出来的高水位值,当pages free低于pages high才会触发swap回收页,就是这么简单啦~

实在担心的话可以用

redis-server --test-memory 需要测试的内存(MB)
登录后复制

测试一下,系统就会在给定的内存下跑测试。

原文地址:Linux下Redis内存优化, 感谢原作者分享。

09-19 00:05