Fork操作

image-20190805185905325

image-20190805185928870

Redis 常见问题之-fork操作

1、fork操作

（1）同步操作

虽然fork同步操作是非常快的，但是如果需要同步的数据量过大，fork就会阻塞redis主进程。

（2）与内存量息息相关

内存越大，fork同步数据耗时越长，当然也跟服务器有关，服务器有物理机，也有虚拟机。

（3）info:latest_fork_usec

使用此命令可以查看持久化花费的时间，如果持久化时间过长，就会造成卡顿。

例如：如果redis此时QPS上万，此时redis正在持久化，而且持久化时间比较长（1s或者10几秒），这个时候就会严重阻塞redis。

2、改善fork

（1）优先使用物理机或者高效的虚拟机支持fork操作

（2）控制redis实际最大可用内存：maxmemory

（3）合理配置linux内存分配策略：vm.overcommit_memory=1

（4）降低fork频率：例如放宽AOF重写自动触发时机，减少不必要的全量复制。

子进程开销和优化

image-20190805190324426

image-20190805190406619

image-20190805190421457

image-20190805190428197

image-20190805190435012

AOF追加阻塞

image-20190805190504946

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

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