nosql----redis性能优化

1.fork耗时致使高并发请求延时

RDB和AOF的时候，AOF rewrite，耗费磁盘IO的过程，主进程fork子进程fork的时候，子进程是须要拷贝父进程的空间内存页表的，也是会耗费必定的时间的。

通常来讲，若是父进程内存有1个G的数据，那么fork可能会消耗在20ms左右，若是是10G-30G，那就会消耗几百毫秒的时间。info stats中的latest_fork_usec,能够看到最近一次form的时长。

redis单机QPS通常在几万，fork可能一会儿就会拖慢几万条操做的请求时长，从几毫秒变成1秒。

优化思路

fork耗时跟redis主进程的最大内存有关系，通常控制redis的内存在10GB之内。

 

2.AOF的阻塞问题

redis将数据写入AOF缓冲器，单独开一个线程作fsync操做，每秒一次。

可是redis主线程会检查两次fsync的时间，若是距离上次fsync时间超过了2秒，那么写请求就会阻塞everysec，最多丢失2秒的数据。

一旦fsync超过2秒的延时，整个redis就被拖慢。

优化思路，优化硬盘写入速度，建议采用SSD，不要用普通的机械键盘。

 

3.主从复制延迟问题

主从复制可能会超时严重，这个时候须要良好的监控和报警机制。

在info replication中，能够看到master和slave复制的offset，作一个差值就能够看到对应的延迟量，若是延迟过多，那么就进行报警。

 

4.主从复制风暴问题

若是一会儿让多个slave从master去执行全量复制，一份大的rdb同事发送到多个slave，会致使网络带宽被严重占用，若是一个master真的要挂载多个slave，那尽可能用树状结构，不要用星型结构。

例如：

这个就是树形结构。

 

5.vm.overcommit_memory

0：检查有没有足够内存，没有的话申请内存失败。

1：容许使用内存直到用完为止。

2：内存地址空间不能超过swap + 50%

 

若是是0的话，可能致使相似fork等操做执行失败，申请不到足够的内存空间。

cat  /proc/sys/vm/overcommit_memory

echo "vm.overcommit_memory=1" >> /etc/sysctl.conf

sysctl vm.overcommit_memory=1

 

6.swapiness

cat /proc/version,查看linux内核版本

若是linux内核版本<3.5,那么swapiness设置为0，这样系统宁愿swap也不会oom killer

若是linux内核版本>3.5,那么swapiness设置为1，这样系统宁愿swap也不会oom killer

保证redis不会被杀掉

echo 1 > /proc/sys/vm/swapiness

echo vm.swapiness=1 >> /etc/sysctl.conf

 

7.最大打开文件句柄

ulimit -Sn 10032

 

8.tcp baklog

cat /proc/sys/net/core/somaxconn

echo 511 > /proc/sys/net/core/somaxconn

 

9.redis是单线程的，当数据量大的时候，不能用keys命令，不然会形成宕机，可用scan命令代替。