百度360必应搜狗淘宝本站头条
当前位置:网站首页 > 技术文章 > 正文

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.**确保域名已解析**...

取消回复欢迎 发表评论: