目前ELK中用到的redis经常出现一些问题,例如:
1 redis中的连接超过限制。例如10.120.31.142上使用redis-cli进入操作时报连接数超过阈值。这个设置默认是10000,在redis目录下的redis.conf文件中设置,参数名为maxclients。
ERR max number of clients reached
关于这个问题,从redis服务器中使用netstat -anp|grep "127.0.0.1"可以看到本机上的logstash占用了大量的redis连接没有释放,导致了这个问题。所以临时方案时将logstash重启即可。
另外,下面代码可以检测到连接超值的错误。
def test_conn():
logger.debug('test redis connection')
temp_list = []
for i in range(10001):
rd = redis.Redis(host='10.120.20.208', port=6379)
logger.debug('index %s, size = %s'%(i, rd.llen('monitor_test')))
temp_list.append(rd)
logger.debug('end of test')
2 出错如下:
12792:M 13 Apr 03:21:08.095 # Can't save in background: fork: Cannot allocate memory
10.120.20.208:
[root@localhost ~]# free -g
total used free shared buff/cache available
Mem: 7 7 0 0 0 0
Swap: 11 8 3
[root@localhost ~]#
我自己理解是redis在做save操作时内存不够。查看了服务器发现swap设置为0,所以就设置了swap,但是在设置swap后,虽然swap被使用的很多,但是还是这个问题还是依然出现。
在/etc/sysctl.conf中设置vm.overcommit_memory=1,执行sysctl -p操作使之生效。做完操作后redis-cli命令台再没有报错“Can't save in background: fork: Cannot allocate memory”。
参考这里:http://blog.csdn.net/zqz_zqz/article/details/53384854
3 redis处理慢的问题。在服务器OS上执行命令时,系统反应很慢。
可以看到io wait很高,对vda的写很重。这里的vda是系统磁盘,应该是redis做save操作,保存快照到本地(也就是它的安装目录,这台机器安装目录在/opt下,所以vda高)的一个操作。
avg-cpu: %user %nice %system %iowait %steal %idle
21.97 0.00 4.98 44.19 0.89 27.97
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
vda 132.50 332.00 48632.00 664 97264
dm-0 0.00 0.00 0.00 0 0
dm-1 0.00 0.00 0.00 0 0
dm-2 0.00 0.00 0.00 0 0
vdc 0.00 0.00 0.00 0 0
dm-3 0.00 0.00 0.00 0 0
avg-cpu: %user %nice %system %iowait %steal %idle
23.01 0.00 3.16 25.66 0.00 48.17
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
vda 6.50 8.00 2804.00 16 5608
dm-0 0.00 0.00 0.00 0 0
dm-1 0.00 0.00 0.00 0 0
dm-2 0.00 0.00 0.00 0 0
vdc 0.00 0.00 0.00 0 0
dm-3 0.00 0.00 0.00 0 0
avg-cpu: %user %nice %system %iowait %steal %idle
22.97 0.00 4.82 55.08 0.89 16.24
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
vda 60.00 94.00 26144.00 188 52288
dm-0 0.00 0.00 0.00 0 0
dm-1 0.00 0.00 0.00 0 0
dm-2 0.00 0.00 0.00 0 0
vdc 0.00 0.00 0.00 0 0
dm-3 0.00 0.00 0.00 0 0
avg-cpu: %user %nice %system %iowait %steal %idle
20.56 0.00 3.70 59.26 0.26 16.22
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
vda 123.00 1458.00 36350.00 2916 72700
dm-0 0.00 0.00 0.00 0 0
dm-1 0.00 0.00 0.00 0 0
dm-2 0.00 0.00 0.00 0 0
vdc 0.00 0.00 0.00 0 0
dm-3 0.00 0.00 0.00 0 0
从redis的日志nohup.out(因为启动方式为./redis-server &,所以生成)看到两种问题:
一是上个主题说到的“Can't save in background: fork: Cannot allocate memory”,而是save(两种save,再讨论吧)操作台频繁。所以出现这种情况,IO写很厉害,CPU等待很高。解决方式有两个,都是参数的设置,一是stop-writes-on-bgsave-error,这个参数的意思是在bgsave出错时不会停止对用户的服务,将它改为no,就是不做stop行为,用户不受影响。
二是save参数,它代表了做快照的条件,有些类似oracle在哪些情况下会写archivelog。save默认值为“3600 1 300 100 60 10000”,即三对条件。最后一对60,10000的意思是在60秒内,有10000个键值修改。针对我们的条件当日志系统数据量很大时是可能经常满足这个条件的,所以我的选择是丢掉最后一对条件。
127.0.0.1:6379> config get save
1) "save"
2) "3600 1 300 100 60 10000"
127.0.0.1:6379>
127.0.0.1:6379> config set save "3600 1 200 100"
OK
(0.96s)
127.0.0.1:6379> config get save
1) "save"
2) "3600 1 200 100"
127.0.0.1:6379>
127.0.0.1:6379> config set stop-writes-on-bgsave-error no
OK
127.0.0.1:6379>