redis big key分析及shell删除(redis删除hashkey)
nanshan 2024-11-06 11:15 11 浏览 0 评论
目前coids 8个master节点8个slave节点,把两台机器600G的内存吃完了,有点夸张。业务上的人只管用,并没有过多关注redis的健康状况,经过分析后发现有很多的垃圾数据。
1、153上 节点6379 - 6386上每个几点大约有1300 - 1400W个key。
?
也可以通过redis desktop manager 连接单节点来查看。
?
可以看到这些key的数量是动态变化的。是因为有的key设定了过期时间代表它已经过期了,关于设定了expire的key何时释放空间?这篇文章中 内存溢出控制策略 有详细阐述。
2、查找big key,redis 提供了一个bigkeys的命令。
得到的结果不一定准确,是因为其统计key的数据规模并不是占用内存最大的key。
bigkeys的原理,非常简单,通过scan命令遍历,各种不同数据结构的key,分别通过不同的命令得到最大的key:
- 如果是string结构,通过strlen判断;
- 如果是list结构,通过llen判断;
- 如果是hash结构,通过hlen判断;
- 如果是set结构,通过scard判断;
- 如果是sorted set结构,通过zcard判断。
redis-cli -p 6380 --bigkeys
[root@P1QMSPL2RTM01 ~]# redis-cli -p 6380 --bigkeys
# Scanning the entire keyspace to find biggest keys as well as
# average sizes per key type. You can use -i 0.1 to sleep 0.1 sec
# per 100 SCAN commands (not usually needed).
......
-------- summary -------
Sampled 13788262 keys in the keyspace!
Total key length in bytes is 376277646 (avg len 27.29)
Biggest string found 'RPT_20200327044033141' has 15102 bytes
Biggest list found 'opehis:A196E06WBE' has 1058 items
Biggest hash found 'HMS:ERROR:HMS_ERROR2' has 2393 fields
Biggest zset found 'history:L6400' has 4736943 members
12788812 strings with 367806347 bytes (92.75% of keys, avg size 28.76)
915321 lists with 8590020 items (06.64% of keys, avg size 9.38)
0 sets with 0 members (00.00% of keys, avg size 0.00)
4397 hashs with 30777 fields (00.03% of keys, avg size 7.00)
79732 zsets with 98114217 members (00.58% of keys, avg size 1230.55)
#!/bin/bash
#/usr/local/codis/src/github.com/CodisLabs/codis/bin/redis-cli -p 6379 -i 0.1 --bigkeys >/home/scripts/6379_153.log
#sleep 40m
#/usr/local/codis/src/github.com/CodisLabs/codis/bin/redis-cli -p 6380 -i 0.1 --bigkeys >/home/scripts/6380_153.log
#sleep 40m
#/usr/local/codis/src/github.com/CodisLabs/codis/bin/redis-cli -p 6381 -i 0.1 --bigkeys >/home/scripts/6381_153.log
#sleep 40m
#/usr/local/codis/src/github.com/CodisLabs/codis/bin/redis-cli -p 6382 -i 0.1 --bigkeys >/home/scripts/6382_153.log
#sleep 40m
/usr/local/codis/src/github.com/CodisLabs/codis/bin/redis-cli -p 6383 -i 0.1 --bigkeys >/home/scripts/6383_153.log
sleep 40m
/usr/local/codis/src/github.com/CodisLabs/codis/bin/redis-cli -p 6384 -i 0.1 --bigkeys >/home/scripts/6384_153.log
sleep 40m
/usr/local/codis/src/github.com/CodisLabs/codis/bin/redis-cli -p 6385 -i 0.1 --bigkeys >/home/scripts/6385_153.log
sleep 40m
/usr/local/codis/src/github.com/CodisLabs/codis/bin/redis-cli -p 6386 -i 0.1 --bigkeys >/home/scripts/6386_153.log
事实上并不用在master上做这个操作,因为master和slave上的数据是同步的,在master上执行此命令可能会严重阻塞client的写命令,尽管使用了-i 0.1 这个参数。
尽管是统计某个key的数据规模,但是看到这些数据有点夸张,有的key竟然还是19年6月的甚至更早,history:L6400 竟然能有470W个value,而这仅仅是一个站点的数据。
事实上,是有一只删除redis 旧key的程序,可是通过分析其逻辑是典型的顾头不顾尾。那当务之急就是为何释放redis的内存,因为redis服务器的内存使用率一直高达99%。
删除当然是找数据最多的,这个key是 zset类型。用了几个小时学习了sorted set的基本使用方法。
删除的逻辑大致是:遍历站点list,拼凑history:ope这个key,然后用zremrangebyscore删除,score根据实际业务来决定。
删除脚本如下
#!/bin/bash
#/usr/local/codis/src/github.com/CodisLabs/codis/bin/redis-cli -p 6379 -i 0.1 --bigkeys >/home/scripts/6379_153.log
#redis-cli -p 6385 zscan history:L7100 0 match '*:*:*:*:*:**M' count 10000 >history_ope.log
#redis-cli -p 6385 zrangebyscore history:L7100 -inf +inf WITHSCORES > history_L7100.log
#sleep 5s
#2017-01-01 00:00:00 ->
#fromTime='1483200000'
#2018-12-31 23:59:59 ->
#toTime='1546271999'
#2018-12-31 23:59:59 ->
fromTime='1546271999'
#2019/08/31 23:59:59
toTime='1567267199'
logname='del_19_1-8.log'
bkname='del_19_1-8.bk'
TIME=$(date '+%Y%m%d%H%M%S')
count=0
#path='/home/scripts/test/opeList.txt'
path='/home/scripts/test/delete/opeList.txt'
while read -r ope
do
#for ope in $(cat ${path}) //在执行删除的时候遇到过效能问题,例如删除result:glass这个key的时候每次读取5-7W行数据然后进行后面的逻辑发现需要2300s,如果减少数据量到2W速度能到100s,这个差距由点大,用for循环每次读一行比从while缓存中读快吗? 改天测试一下
#do
var1=$(/usr/local/codis/src/github.com/CodisLabs/codis/bin/redis-cli -p 19000 zrangebyscore history:${ope} $fromTime $toTime|wc -l)
# zcard 统计数量可考虑使用该命令计算
#count=$($[count] + $[var1])
count=`expr $count + $var1`
#echo $var1
/usr/local/codis/src/github.com/CodisLabs/codis/bin/redis-cli -p 19000 zremrangebyscore history:${ope} $fromTime $toTime
sleep 1s
echo "$TIME /usr/local/codis/src/github.com/CodisLabs/codis/bin/redis-cli -p 19000 zremrangebyscore history:${ope} $fromTime $toTime " >> /home/scripts/test/delete/$bkname
echo "$TIME ope: $ope,delQty: $var1 " >> /home/scripts/test/delete/$logname
#test
#redis-cli -p 6385 zscan history:${ope} 0 match '*:*:*:*:*:**M' count 1000 > history_6383_${ope}.log
#done
done < opeList.txt
echo "totalQty: $count" >> /home/scripts/test/delete/$logname
删除数据量统计
时间 | 17年- 18年 | 19年1-6月 |
Value数量 | 约1000W | 36970313 |
Key数量 | ? | 211 |
内存 | 1.6GB | 7.2GB |
这总算是解了燃眉之急,至少redis能撑2-5天。毕竟不是长久之计。
内存使用一个脚本估算出来的:
精确评估 history:ope 的大小
概述:在测试环境,将history:ope zadd 10000笔, 打印前后的内存变化,同时根据模型计算,比较两者的差距。
Shell 脚本如下
#!/bin/sh
key="history:A3850"
old_memory=`/usr/local/bin/redis-cli -h 0 -p 6380 info|grep used_memory:|awk -F: '{printf "%d", $2}'`
echo "before test, memory used: $old_memory"
#for((i=100; i<900; i++))
#do
for((j=1483200000; j<1483210000; j++))
do
/usr/local/bin/redis-cli -h 0 -p 6380 zadd $key $j AOIH0200:AOIH0200:A3850E495A1:A1495A1ANK1:A183A00VN01:$j:M > /dev/null
done
sleep 0.5
#done
new_memory=`/usr/local/bin/redis-cli -h 0 -p 6380 info|grep used_memory:|awk -F: '{printf "%d", $2}'`
echo "after test, memory used: $new_memory"
let difference=new_memory-old_memory
echo "difference is: $difference"
[root@gptest01 redis]# ./evaluateHisOpeMem.sh
before test, memory used: 415131248
after test, memory used: 417395400
difference is: 2264152
一个key的写入10000笔数据,需要占用2.16MB
故4000W的value规模可以释放8.5GB的数据
前期用模型估算出来的大小为7G左右。
Value 长度 67byte
共7段
平均每段 = (8 + 8 + 11 + 11 + 11 + 10 + 1)/7 = 8.58byte≈9byte
?
参考:
https://www.jianshu.com/p/5c5dc0d7d776
http://doc.redisfans.com/index.html
3、利用rdb tool来讲dump导出写入mysql 通过下sql 的方式查redis数据。
rdb -c memory -l 5 dump.rdb
找出前5大key。
[root@P1QMSPL2RTM01 redis]# rdb -c memory -l 5 dump.rdb
database,type,key,size_in_bytes,encoding,num_elements,len_largest_element,expiry
WARNING: python-lzf package NOT detected. Parsing dump file will be very slow unless you install it. To install, run the following command:
pip install python-lzf
后来运维人员装好了rdb tool,经过分析原来result:glassId才是终极大boss。
至此,才算真正意义上找到了”bigkeys”,这才是占用reids最大的内存了。
在处理这次事故中,发现目前架构是主从读写分离的架构,在重放slave的aof文件时发生了瞬时读取不到key的情况,着实让人操心。关于此请参照我写的另外一篇。
-------------update 2020年4月26日08:44:45 -----------------------
还有一点是非常奇怪的现象:
旧的数据清理完了之后发现一个奇怪的现象,6385节点的内存交其他节点多10GB,这是很奇怪的,通过codis-proxy写入key时会根据冗余校验算法分配到每一个slot上,理论上来说数据倾斜不会这么严重。
?
对该节点重新做了bgsave ,分析dump之后,发现更奇怪的事情, 某些过期数据残存在6385上,透过proxy竟然访问不到,这是为何呢???
[root@P1PL2RTM01 redis]# redis-cli -p 19000 zrange result:A18BR04NAY 0 -1
(empty list or set)
You have new mail in /var/spool/mail/root
[root@P1PL2RTM01 redis]# redis-cli -p 6385 zrange result:A18BR04NAY 0 -1
1) "{\"actualEqptId\":\"MSPU0200\",\"defectCnt\":0,\"glassId\":\"A18BR04NAY\",\"ifPreProcess\":true,\"ooc\":false,\"oos\":false,\"panelCnt\":8,\"processEndTime\":1543355980,\"ruleSeqId\":3277}"
2) "{\"actualEqptId\":\"MSPU0200\",\"defectCnt\":2,\"glassId\":\"A18BR04NAY\",\"ifPreProcess\":true,\"ooc\":false,\"oos\":false,\"panelCnt\":8,\"processEndTime\":1543355980,\"ruleSeqId\":3298}"
针对目前的怪现象:
codisproxy把某个key写在哪个slot了?这些信息会记录在zk吗?client现在想读刚才写入的数据 应该从哪个slot读呢?
是不是可以从这几个方面入手呢?
更详尽的内容请参考:
https://redis.io/topics/rediscli#scanning-for-big-keys
源代码分析
https://blog.csdn.net/aoerqileng/article/details/86687499
?
相关推荐
- Let’s Encrypt免费搭建HTTPS网站
-
HTTPS(全称:HyperTextTransferProtocoloverSecureSocketLayer),是以安全为目标的HTTP通道,简单讲是HTTP的安全版。即HTTP下加入...
- 使用Nginx配置TCP负载均衡(nginx tcp负载)
-
假设Kubernetes集群已经配置好,我们将基于CentOS为Nginx创建一个虚拟机。以下是实验种设置的详细信息:Nginx(CenOS8Minimal)-192.168.1.50Kube...
- Nginx负载均衡及支持HTTPS与申请免费SSL证书
-
背景有两台minio文件服务器已做好集群配置,一台是192.168.56.41:9000;另一台是192.168.56.42:9000。应用程序通过Nginx负载均衡调用这两台minio服务,减轻单点...
- HTTPS配置实战(https配置文件)
-
原因现在网站使用HTTPS是规范操作之一,前些日子买了腾讯云服务,同时申请了域名http://www.asap2me.top/,目前该域名只支持HTTP,想升级为HTTPS。关于HTTPS的链接过程大...
- 只有IP地址没有域名实现HTTPS访问方法
-
一般来说,要实现HTTPS,得有个注册好的域名才行。但有时候呢,咱只有服务器的IP地址,没注册域名,这种特殊情况下,也能照样实现HTTPS安全访问,按下面这些步骤来就行:第一步,先确认公网...
- 超详解:HTTPS及配置Django+HTTPS开发环境
-
众所周知HTTP协议是以TCP协议为基石诞生的一个用于传输Web内容的一个网络协议,在“网络分层模型”中属于“应用层协议”的一种。在这里我们并不研究该协议标准本身,而是从安全角度去探究使用该协议传输数...
- Godaddy购买SSL之后Nginx配置流程以及各种错误的解决
-
完整流程:参考地址:https://sg.godaddy.com/zh/help/nginx-generate-csrs-certificate-signing-requests-3601生成NGI...
- Nginx从安装到高可用,一篇搞定(nginx安装与配置详解)
-
一、Nginx安装1、去官网http://nginx.org/下载对应的nginx包,推荐使用稳定版本2、上传nginx到linux系统3、安装依赖环境(1)安装gcc环境yuminstallgc...
- 阿里云免费证书申请,配置安装,使用tomcat,支持http/https访问
-
参数说明商品类型默认已选择云盾证书服务(无需修改)。云盾证书服务类型SSL证书服务的类型。默认已选择云盾SSL证书(无需修改),表示付费版SSL证书。如果您需要免费领取或付费扩容DV单域名证书【免费试...
- 你试过两步实现Nginx的规范配置吗?极速生成Nginx配置小工具
-
NGINX是一款轻量级的Web服务器,最强大的功能之一是能够有效地提供HTML和媒体文件等静态内容。NGINX使用异步事件驱动模型,在负载下提供可预测的性能。是当下最受欢迎的高性能的Web...
- 从零开始搭建HTTPS服务(搭建https网站)
-
搭建HTTPS服务的最初目的是为了开发微信小程序,因为wx.request只允许发起HTTPS请求,并且还必须和指定的域名进行网络通信。要从零开始搭建一个HTTPS的服务需要下面4...
- 群晖NAS使用官网域名和自己的域名配置SSL实现HTTPS访问
-
安全第一步,群晖NAS使用官网域名和自己的域名配置SSL实现HTTPS访问【新手导向】NAS本质还是一个可以随时随地访问的个人数据存储中心,我们在外网访问的时候,特别是在公网IP下,其实会面临着很多安...
- 让网站快速升级HTTPS协议提高安全性
-
为什么用HTTPS网络安全越来越受到重视,很多互联网服务网站,都已经升级改造为https协议。https协议下数据包是ssl/tcl加密的,而http包是明文传输。如果请求一旦被拦截,数据就会泄露产生...
- 用Https方式访问Harbor-1.9版本(https访问流程)
-
我上周在头条号写过一篇原创文章《Docker-Harbor&Docker-kitematic史上最详细双系统配置手册》,这篇算是它的姊妹篇吧。这篇文章也将用到我在头条写的另一篇原创文章的...
- 如何启用 HTTPS 并配置免费的 SSL 证书
-
在Linux服务器上启用HTTPS并配置免费的SSL证书(以Let'sEncrypt为例)可以通过以下步骤完成:---###**一、准备工作**1.**确保域名已解析**...
你 发表评论:
欢迎- 一周热门
-
-
极空间如何无损移机,新Z4 Pro又有哪些升级?极空间Z4 Pro深度体验
-
如何在安装前及安装后修改黑群晖的Mac地址和Sn系列号
-
爱折腾的特斯拉车主必看!手把手教你TESLAMATE的备份和恢复
-
10个免费文件中转服务站,分享文件简单方便,你知道几个?
-
[常用工具] OpenCV_contrib库在windows下编译使用指南
-
日本海上自卫队的军衔制度(日本海上自卫队的军衔制度是什么)
-
【系统配置】信创终端挂载NAS共享全攻略:一步到位!
-
UOS服务器操作系统防火墙设置(uos20关闭防火墙)
-
Ubuntu系统Daphne + Nginx + supervisor部署Django项目
-
WindowsServer2022|配置NTP服务器的命令
-
- 最近发表
- 标签列表
-
- linux 查询端口号 (58)
- docker映射容器目录到宿主机 (66)
- 杀端口 (60)
- yum更换阿里源 (62)
- internet explorer 增强的安全配置已启用 (65)
- linux自动挂载 (56)
- 禁用selinux (55)
- sysv-rc-conf (69)
- ubuntu防火墙状态查看 (64)
- windows server 2022激活密钥 (56)
- 无法与服务器建立安全连接是什么意思 (74)
- 443/80端口被占用怎么解决 (56)
- ping无法访问目标主机怎么解决 (58)
- fdatasync (59)
- 405 not allowed (56)
- 免备案虚拟主机zxhost (55)
- linux根据pid查看进程 (60)
- dhcp工具 (62)
- mysql 1045 (57)
- 宝塔远程工具 (56)
- ssh服务器拒绝了密码 请再试一次 (56)
- ubuntu卸载docker (56)
- linux查看nginx状态 (63)
- tomcat 乱码 (76)
- 2008r2激活序列号 (65)