redis经典问题：Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without ...

本文分享自微信公众号 - DBA随笔(gh_acc2bbc0d447)，作者：DBA随笔

我们的场景结论，

1，使用的nfs文件系统 挂载的远端存储，存的aof文件。

2，盘远端网络存储又不是ssd高性能io盘。属于远端网络+慢io

3，设置的appendfsync everysec

4，redis再容器里

所有性能低的场景都碰上了，所以报Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis

本质是没有，按最佳实践，标准化的去部署。

01、问题描述

今天早晨遇到一个Redis的线上的问题，也算是一个Redis的经典问题了，这里记录下分析和排查过程，希望对大家有所帮助。

问题背景：

业务侧反馈服务有超时，10:30分左右出现了大量的IO timeout的报警

业务的监控图脱敏后如下，纵坐标是延时的请求次数，可以看到，10:30分左右，突然飙升很多。

报警信息中详细定位了报警的Redis端口和域名，可以确定到某一台服务器的IP地址上，那其实只要对这个特定的IP地址进行分析就好了。

02、分析定位过程

首先先查看对应的连接数，发现10：32分的时候，确实有连接数上升的问题：

再次查看Redis日志中发现有大量重复的告警内容：

24:S 16 Aug 10:32:03.357 * Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis. 24:S 16 Aug 10:32:05.067 * Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis. 24:S 16 Aug 10:32:39.058 * Asynchronous AOF fsync is taking too