博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
ELK中的redis的问题记录
阅读量:6418 次
发布时间:2019-06-23

本文共 4512 字,大约阅读时间需要 15 分钟。

hot3.png

目前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   availableMem:              7           7           0           0           0           0Swap:            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”。

参考这里:

 

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.97Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtnvda             132.50       332.00     48632.00        664      97264dm-0              0.00         0.00         0.00          0          0dm-1              0.00         0.00         0.00          0          0dm-2              0.00         0.00         0.00          0          0vdc               0.00         0.00         0.00          0          0dm-3              0.00         0.00         0.00          0          0avg-cpu:  %user   %nice %system %iowait  %steal   %idle          23.01    0.00    3.16   25.66    0.00   48.17Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtnvda               6.50         8.00      2804.00         16       5608dm-0              0.00         0.00         0.00          0          0dm-1              0.00         0.00         0.00          0          0dm-2              0.00         0.00         0.00          0          0vdc               0.00         0.00         0.00          0          0dm-3              0.00         0.00         0.00          0          0avg-cpu:  %user   %nice %system %iowait  %steal   %idle          22.97    0.00    4.82   55.08    0.89   16.24Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtnvda              60.00        94.00     26144.00        188      52288dm-0              0.00         0.00         0.00          0          0dm-1              0.00         0.00         0.00          0          0dm-2              0.00         0.00         0.00          0          0vdc               0.00         0.00         0.00          0          0dm-3              0.00         0.00         0.00          0          0avg-cpu:  %user   %nice %system %iowait  %steal   %idle          20.56    0.00    3.70   59.26    0.26   16.22Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtnvda             123.00      1458.00     36350.00       2916      72700dm-0              0.00         0.00         0.00          0          0dm-1              0.00         0.00         0.00          0          0dm-2              0.00         0.00         0.00          0          0vdc               0.00         0.00         0.00          0          0dm-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 save1) "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 save1) "save"2) "3600 1 200 100"127.0.0.1:6379> 127.0.0.1:6379> config set stop-writes-on-bgsave-error noOK127.0.0.1:6379>

 

转载于:https://my.oschina.net/shawnplaying/blog/878996

你可能感兴趣的文章
XML特殊符号
查看>>
kaptcha可配置项
查看>>
JavaMail邮箱验证用户注册
查看>>
系统时间——ntpd
查看>>
反射实现AOP动态代理模式(Spring AOP实现原理)
查看>>
Http协议与缓存
查看>>
监测超过特定内存阀值进程并结束
查看>>
Linux Centos 查询信息
查看>>
android adb命令
查看>>
python “双”稀疏矩阵转换为最小联通量“单”矩阵
查看>>
揭秘天猫双11背后:20万商家600万张海报,背后只有一个鹿班
查看>>
重置mysq root密码脚本
查看>>
我的友情链接
查看>>
MHA配置参数
查看>>
深入理解Lock
查看>>
vim的块选择
查看>>
HTML --块
查看>>
在DLL中获取主进程窗口句柄
查看>>
基于消息队列的双向通信
查看>>
一个不错的loading效果
查看>>