常见的持久化开发与运维问题 fork 操作 fork 操作是一个同步操作,若执行较慢会阻塞 redis 主线程 执行时间与内存量相关:内存越大,耗时越长;虚拟机较慢,真机较快 查看 fork 执行时间,可做监控
info : latest_fork_usec 上一次执行fork的微秒数 改善 fork 优先使用物理机或者高效支持fork操作的虚拟化技术 控制 Redis 实际最大可用内存:maxmemory 合理配置 Linux 内存分配策略 vm.overcommit_memory = 1
默认这个值为 0,表示当发现没有足够内存做内存分配的时候,就不去分配。在内存比较低的时候,会发生fork 阻塞。设置为 1 表示认为机器有足够内存,来做内存分配。 降低 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秒,会发生阻塞。
AOF 阻塞定位 通过Redis日志进行定位。出行这行,即发生阻塞:
Asynchronous AOF fsync is taking too long (disk is busy?) Writing the AOF buffer without waiting for fsync to complete,this may show down Redis 通过 info persistence
命令进行查看:每发生一次,aof_delayed_fsync
会增 1 。
如图,aof_deloayed_fsync:0,说明 aof 并没有发生阻塞。
通过 df -h
和 du -sh
统计整体磁盘情况和查看单独目录点用情况。 优化方法可以参考硬盘优化策略。