redis一些问题

fork操作

• fork操作是一个同步操作，若执行较慢会阻塞redis主线程

• 执行时间与内存量相关：内存越大，耗时越长；虚拟机较慢，真机较快。

• 查看fork执行时间，可做监控

  • info : latest_fork_usec 上一次执行fork的微秒数

• 优先使用物理机或者高效支持fork操作的虚拟化技术

• 控制redis实际最大可用内存

• 合理配置linux内存分配策略 vm.overcommit_memory = 1

  • 默认这个值为0，在内存比较低的时候，会发生fork阻塞

• 降低fork频率：例如放宽aof重写自动触发时机，不必要的全量复制

 

 

进程外开销

• cpu开销

  • rdb和aof都会生成文件，属于cpu密集型

  • 优化1：不做cpu绑定，不和cpu密集型的应用部署在同一台服务器上

  • 优化2：避免在单机多部署的场景大量发生aof重写

• 内存

  • 开销：fork内存开销，copy-on-write，子进程会共享父进程的物理内存页，当父进程执行写请求的时候会创建一个副本，此时会消耗内存。即父进程在大量写入的时候，子进程开销会比较大，创建副本。

  • 优化1：防止单机多部署的时候发生大量的重写

  • 优化2：echo never > /sys/kernel/mm/transparent_hugepage/enabled

    • linux内核的2.6.38版本中增加以上配置，支持大的内存页的分配

    • 内存页分配越大，会提高创建副本页的大小，影响性能

• 硬盘

  • 开销：rdb与aof文件写入的场景，可以集合iostat、iotop进行分析

  • 优化1：不要和高硬盘负载服务部署在一起，例如存储服务、消息队列

  • 配置：no-appendfsync-on-rewrite = yes

  • 根据写入量决定磁盘类型：ssd

  • 单机多实例持久化目录可以考虑分盘以及做资源限制，例如cgroup

 

 

aof追加阻塞

redis在执行fsync的时候，redis为了保证aof文件安全性，会校验上次fsync的时间是否大于2秒。若超过2秒，会发生阻塞。

可以通过redis日志进行定位：asynchronous aof fsync is taking too long (disk is busy?)

也可以通过info persistence命令进行查看：每发生一次，aof_delayed_fsync 会增1

优化方法可以参考硬盘优化策略