redis优化

https://blog.csdn.net/crisis_hiding/article/details/81490158

生产环境长时间的运行后,经常会有接口返回数据失败的情况,或者是从监控上发现数据库压力某一时间暴增。查看客户端日志发现这样的错误:

redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool

从错误日志看,是提示无法获取连接。有两种情况:

1、客户端的连接池满了,无法创建新的连接

检查客户端连接最大限制maxActive是否足够

2、redis服务端连接溢出,无法分配新的连接

检查服务端tcp连接:netstat -nat|grep -i "6379"|wc -l

检查服务端连接是否达到最大值:查看服务端支持的最大连接:CONFIG GET maxclients,查看当前服务端建立的   连接:connected_clients

通过上述检查后,发现redis服务端connected_clients连接数持续过高,经常在最大值徘徊。但是结合客户端配置的最大连接配置maxActive,计算出所有客户端连接占满的情况下最大的连接数也达不到connected_clients的连接数。

执行client list命令,发现大量的client的idle时间特别长:

正常的client连接,在持续使用的情况下,是不可能空闲这么长时间,连接长时间空闲,客户端也会关闭连接。

查看redis服务端下面两项配置:

timeout:client连接空闲多久会被关闭(这个配置容易被误导为:连接超时和操作执行超时)

    tcp-keepalive:redis服务端主动向空闲的客户端发起ack请求,以判断连接是否有效

检查上述配置发现 timeout和tcp-keepalive均未启用(均为0),这种情况下,redis服务端没有有效的机制来确保服务端已经建立的连接是否已经失效。当服务器和客户端网络出现闪断,导致tcp连接中断,这种情况下的client将会一直被redis服务端所持有,就会出现上面我们看到的idle时间特长的client连接。

接下来设置timeout和tcp-keepalive来清理失效的连接。



突然间服务不能访问,返回错误:

redis.clients.jedis.exceptions.JedisDataException: MISCONF Redis is configured to save RDB snapshots, but is currently not able to persist on disk. Commands that may modify the data set are disabled. Please check Redis logs for details about the error.

从错误提示,可以看出是向磁盘保存数据失败。引起这个问题的原因一般是内存不足,但是生产环境我们一般都会为系统分配足够的内存运行,而且查看内存情况也显示还有可用内存。

查看redis日志,发现有这个错误:Can’t save in background: fork: Cannot allocate memory

redis在保存内存的数据到磁盘时,为了防止主进程假死,会Fork一个子进程来完成这个保存操作。但是这个Fork的子进程会需要分配和主进程相同的内存,这时候就相当于需要的内存double了,如果这时候可用内存不足以分配需要的内存,将会导致Fock子进程失败而无法保存数据到磁盘。

修改linux内核参数:vm.overcommit_memory=1。至此,问题解决。

overcommit_memory有三种取值:0, 1, 2

0::检查是否有足够的可用内存供进程使用;有则允许申请,否则,内存申请失败,并把错误返回给应用进程;

1:表示内核允许分配所有的物理内存,而不管当前的内存状态如何;

2:表示内核允许分配超过所有物理内存和交换空间总和的内存。



优化总结

1、结合实际使用场景,考虑是否需要用到redis的持久化,如果单纯用来做应用层的缓存(在缓存未命中的情况下访问数据库),可以关闭持久化。

2、缓存模式下,尽量为每块缓存设置时效性,避免冷数据长时间占用资源。

3、生产环境中尽量避免使用keys操作,由于redis是单线程模式,大量的keys操作会阻塞其他的命令执行。

4、设置合理的内存回收策略,保证内存可用性的同时能适当的提供缓存的命中率。

5、提前计算出系统可能会用的内存大小,合理的分配内存。需要注意在开启持久化模式下,需要预留更多的内存提供给Fock的子进程做数据磁盘flush操作。

原文地址:https://www.cnblogs.com/dingpeng9055/p/11801550.html

时间: 2024-08-30 07:29:27

redis优化的相关文章

Redis优化高并发下的秒杀性能

本文内容 使用Redis优化高并发场景下的接口性能数据库乐观锁 随着双12的临近,各种促销活动开始变得热门起来,比较主流的有秒杀.抢优惠券.拼团等等.涉及到高并发争抢同一个资源的主要场景有秒杀和抢优惠券. 前提 活动规则 奖品数量有限,比如100个 不限制参与用户数 每个用户只能参与1次秒杀 活动要求 不能多发,也不能少发,100个奖品要全部发出去 1个用户最多抢1个奖品 遵循先到先得原则,先来的用户有奖品 数据库实现 悲观锁性能太差,本文不予讨论,讨论一下使用乐观锁解决高并发问题的优缺点.数据

一文带你了解Redis优化高并发下的秒杀性能

本文内容 使用Redis优化高并发场景下的接口性能数据库乐观锁 随着双12的临近,各种促销活动开始变得热门起来,比较主流的有秒杀.抢优惠券.拼团等等.涉及到高并发争抢同一个资源的主要场景有秒杀和抢优惠券. 前提 活动规则 奖品数量有限,比如100个 不限制参与用户数 每个用户只能参与1次秒杀 活动要求 不能多发,也不能少发,100个奖品要全部发出去 1个用户最多抢1个奖品 遵循先到先得原则,先来的用户有奖品 数据库实现 悲观锁性能太差,本文不予讨论,讨论一下使用乐观锁解决高并发问题的优缺点.数据

Redis优化经验

内存管理优化 Redis Hash是value内部为一个HashMap,如果该Map的成员数比较少,则会采用类似一维线性的紧凑格式来存储该Map, 即省去了大量指针的内存开销,这个参数控制对应在redis.conf配置文件中下面2项: hash-max-zipmap-entries 64 hash-max-zipmap-value 512 当value这个Map内部不超过多少个成员时会采用线性紧凑格式存储,默认是64,即value内部有64个以下的成员就是使用线性紧凑存储,超过该值自动转成真正的

redis优化配置和redis.conf说明

1. redis.conf 配置参数: #是否作为守护进程运行 daemonize yes #如以后台进程运行,则需指定一个pid,默认为/var/run/redis.pid pidfile redis.pid #绑定主机IP,默认值为127.0.0.1 #bind 127.0.0.1 #Redis默认监听端口 port 6379 #客户端闲置多少秒后,断开连接,默认为300(秒) timeout 300 #日志记录等级,有4个可选值,debug,verbose(默认值),notice,warn

【转载】redis优化

原文链接 批量操作优化: 在使用redis的时候,客户端通过socket向redis服务端发起请求后,等待服务端的返回结果. 客户端请求服务器一次就发送一个报文 -> 等待服务端的返回 -> 关闭连接 如果是100个请求.1000个请求,那就得请求100次.1000次 所以使用多个请求的时候使用管道来操作(如果管道打包的命令太多占用的内存也会越大,适量) 以下是使用3种方式进行的测试(循环写入1000次): public static void main(String[] args) { lo

redis启动时的几个报警错误-redis优化

1)The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128 2)WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcomm

mongodb redis 优化 (centos 7)

mongodb (WARNING: soft rlimits too low) 修改配置文件 /etc/security/limits.conf,添加配置信息: [[email protected] ~]# vi /etc/security/limits.conf mongod soft nofile 64000 mongod hard nofile 64000 mongod soft nproc 32000 mongod hard nproc 32000 mongodb & redis 禁用大

redis优化秒杀系统

用redis提高基于mss的秒杀系统 使用背景: 普通的基于mss框架的系统在并发量不是很高的情况下,对redis的需求不是很高.redis在系统中的角色相当于一个对象缓存器,在高并发的系统中(比如秒杀系统),在某一刻对数据库中的一条数据可能是成千上万的用户同时去访问,系统的用户体验度直接受到数据库的性能的影响.为了保证数据的完整性,用户只能串行访问数据库中的某一条记录.redis则是把记录对应的对象序列化存储在自身的容器中,减少数据库的压力.废话不多说,接下来简单介绍redis的使用. red

Redis优化总结

# 注意在redis.conf中的小聚合数据类型的特殊编码设置(http://carlosfu.iteye.com/blog/2254572)```hash-max-zipmap-entries 64 (hash-max-ziplist-entries for Redis >= 2.6)hash-max-zipmap-value 512 (hash-max-ziplist-value for Redis >= 2.6)list-max-ziplist-entries 512list-max-z