发现阻塞
线上应用服务最先感知到,可在应用方加入异常统计并通过邮件、短信、微信报警。
借助日志系统,统计异常和触发报警逻辑
借助Redis监控系统发现阻塞问题,触发报警。推荐CacheCloud系统。
内在原因
API或数据结构使用不合理
对于高并发场景,避免在大对象上执行算法复杂度超过O(n)O(n)的命令。
发现慢查询:slowlog get {n}
发现大对象:redis-cli -h{ip} -p{port} bigkeys
CPU饱和
CPU饱和指redis把单核CPU跑到100%。
top命令查看redis进程CPU使用率
redis-cli -h{ip} -p{port} –stat获取当前redis使用情况,判断并发是否达到极限
info commandstats 分析命令不合理开销时间,可能过度内存优化
持久化阻塞
1、fork阻塞
发生在RDB或AOF重写时,redis主线程调用fork产生子进程完成持久化文件重写
使用info stats命令获取lastest_fork_usec指标,表示redis最近一次fork操作耗时
2、AOF刷盘阻塞
开启AOF,文件刷盘一般每秒一次,硬盘压力过大时,fsync需要等待写入完成
查看redis日志或info persistence统计中的aof_delayed_fsync指标
可使用iotop差可能哪个进程消耗过多的硬盘资源
3、HugePage写操作阻塞
对于开启Transparent HugePages的操作系统,每次写命令引起的复制内存页单位由4KB变为2MB
会拖慢写操作的执行时间,导致大量写操作慢查询
外在原因
CPU竞争
1、进程竞争:redis是典型的CPU密集型应用。使用top、sar命令定位CPU消耗的时间点和进程
2、绑定CPU:常见优化是把redis进程绑定到CPU上,较低CPU上下文切换开销,如果fork子进程做了CPU绑定,则父子进程存在激烈的CPU竞争,极大影响redis稳定性。
内存交换
如果操作系统把redis使用的内存换出到硬盘上,会导致发生交换后的redis性能急剧下降。
识别redis内存交换的检查方法:
1、查询redis进程号
redis-cli info server | grep process_id
2、根据进程号查询内存交换信息
cat /proc/{process_id}/smaps | grep Swap
如果交换量都是0KB或者个别4KB,是正常现象。
预防内存交换:
1、保证机器充足的可用内存
2、确保所有redis示例设置最大可用内存(maxmemory),防止极端情况下redis内存不可控的增长
3、降低系统使用swap优先级,如 echo 10>/proc/sys/vm/swappiness
网络问题
1、连接拒绝
网络闪断:一般在网络割接或带宽耗尽的情况
redis连接拒绝:
连接数大于maxclients时拒绝新的连接进入,info stats的rejected_connections指标
客户端访问redis尽量采用NIO长连接或连接池的方式
redis用于大量分布式节点访问且生命周期较短的场景(如Map/Reduce)时,建议设置tcp-keepalive和timeout参数让redis主动检查和关闭无效连接
连接溢出:
进程限制:进程可打开最大文件数控制,ulimit -n,通常1024,大量连接的redis需要增大该值
backlog队列溢出:系统对于特定端口tcp连接使用backlog队列保存,redis默认511,系统backlog默认128,线上可使用cron定时执行netstat -s | grep overflowed统计
2、网络延迟
测量机器之间网络延迟
redis-cli -h{ip} -p{port} –latency redis-cli -h{ip} -p{port} –latency-history 默认15秒完成一行统计,-i控制采样时间 redis-cli -h{ip} -p{port} –latency-dist 统计图展示,每1秒采样一次
3、网卡软中断
单个网卡队列只能使用一个CPU,高并发下网卡数据交互都集中在同一个CPU,导致无法充分利用多核CPU的情况。
一般出现在网络高流量吞吐的场景
更多redis知识请关注redis入门教程栏目。
以上就是Redis阻塞原因详解的详细内容,更多请关注php中文网其它相关文章!
已抢62032个
抢已抢110692个
抢已抢46634个
抢已抢133387个
抢已抢32167个
抢