Redis主节点内存占用过高

0. 基本情况

Redis采用集群模式,560个主节点,主从比为1:1,单台机器上为16个节点。info memory观察到主节点A单个Redis内存used_memory_rss_human为9.2G(设置的maxmemory_human为6G)超过最大值设置。

1.查看客户端连接情况

[[email protected] A ~]# redis-cli -p 9001 info clients

# Clients

connected_clients:4705

client_longest_output_list:204928

client_biggest_input_buf:0

blocked_clients:0

通过client_longest_output_list发现有大量的输出排队,进一步观察所有的客户端均存在这个情况。

在A机器上刷客户端输出list:

CLIENT_A:9001# Clients

client_longest_output_list:491335

CLIENT_A:9002# Clients

client_longest_output_list:520840

CLIENT_A:9003# Clients

client_longest_output_list:486498

CLIENT_A:9004# Clients

client_longest_output_list:485387

CLIENT_A:9005# Clients

client_longest_output_list:480000

CLIENT_A:9006# Clients

client_longest_output_list:537211

CLIENT_A:9007# Clients

client_longest_output_list:487594

CLIENT_A:9008# Clients

client_longest_output_list:490037

CLIENT_A:9009# Clients

client_longest_output_list:478734

CLIENT_A:9010# Clients

client_longest_output_list:524717

CLIENT_A:9011# Clients

client_longest_output_list:487200

CLIENT_A:9012# Clients

client_longest_output_list:491687

CLIENT_A:9013# Clients

client_longest_output_list:483900

CLIENT_A:9014# Clients

client_longest_output_list:524557

CLIENT_A:9015# Clients

client_longest_output_list:497967

CLIENT_A:9016# Clients

client_longest_output_list:484250

2.输出内存占用不为0 的内容

[[email protected] A redis-node]# redis-cli -p 9001 client list |grep -v "omem=0"

id=843 addr=client_B:53475 fd=2248 name= age=582784 idle=0 flags=S db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=456078 omem=7446059139 events=rw cmd=replconf

通过cmd可知是主从同步占用大量输出内存

3.检查统计值

有问题Client A的从client_B

[[email protected] 9001]# redis-cli -p 9001

127.0.0.1:9001> info stats

# Stats

total_connections_received:2

total_commands_processed:25

instantaneous_ops_per_sec:0

total_net_input_bytes:1280055129

total_net_output_bytes:36461

instantaneous_input_kbps:192.22

instantaneous_output_kbps:0.00

rejected_connections:0

正常的机器C的从Client D

[[email protected] D redis-node]# redis-cli -p 9001

127.0.0.1:9001> info Stats

# Stats

total_connections_received:10

total_commands_processed:23220212769

instantaneous_ops_per_sec:18281

total_net_input_bytes:3405817622262

total_net_output_bytes:59530419

instantaneous_input_kbps:2882.54

instantaneous_output_kbps:0.03

rejected_connections:0

输入速度差了10倍,其他配置均一样,怀疑是网络问题。

4.检查网络时延

机器A的从client_B

[[email protected] redis-node]# traceroute client_B

traceroute to client_B (client_B), 30 hops max, 60 byte packets

1  *.*.*.254   0.752 ms  0.809 ms  0.900 ms

2  *.*.*.133  2.164 ms  2.170 ms  2.157 ms

3  * * *

4  * * *

5  *.*.*.2  163.542 ms  163.940 ms  164.181 ms

6  client_B (client_B)  160.995 ms  156.202 ms  158.603 ms

Clinet C的从Client D

[[email protected] ~]# traceroute Client D

traceroute to Client D (Client D), 30 hops max, 60 byte packets

1  *.*.*.254   0.732 ms  0.799 ms  0.897 ms

2  *.*.*.133   3.147 ms  3.182 ms  3.168 ms

3  * * *

4  * * *

5  *.*.*.2   5.537 ms  5.788 ms  5.961 ms

6  Client D (Client D)  1.953 ms  1.960 ms  1.956 ms

测试机器A到机器D性能

[[email protected] 42 9001]#  traceroute Client D

traceroute to Client D (Client D), 30 hops max, 60 byte packets

1  *.*.*.254 (10.180.128.254)  0.738 ms  0.800 ms  0.889 ms

2  *.*.*.133 (10.180.176.133)  2.156 ms  2.190 ms  2.177 ms

3  * * *

4  * * *

5  *.*.*.2   5.768 ms  5.942 ms  6.114 ms

6  Client D (Client D)  1.940 ms  1.964 ms  1.948 ms

说明是机器A到client_B网络有问题

5.解决办法

更换从的机器到client_B到clinet E

启动后机器A上9001 内存使用情况

127.0.0.1:9001> info memory

# Memory

used_memory:2771776520

used_memory_human:2.58G

used_memory_rss:3403390976

used_memory_rss_human:3.17G

used_memory_peak:18154232496

used_memory_peak_human:16.91G

used_memory_peak_perc:15.27%

used_memory_overhead:758586508

used_memory_startup:8105584

used_memory_dataset:2013190012

used_memory_dataset_perc:72.84%

total_system_memory:540783263744

total_system_memory_human:503.64G

used_memory_lua:37888

used_memory_lua_human:37.00K

maxmemory:6442450944

maxmemory_human:6.00G

maxmemory_policy:volatile-ttl

mem_fragmentation_ratio:1.23

mem_allocator:jemalloc-4.0.3

active_defrag_running:0

lazyfree_pending_objects:0

127.0.0.1:9001>

6.解决后观察

Client E内存同步情况

127.0.0.1:9001> info stats

# Stats

total_connections_received:37

total_commands_processed:5318696

instantaneous_ops_per_sec:19310

total_net_input_bytes:1711079396

total_net_output_bytes:4954958

instantaneous_input_kbps:2967.88

instantaneous_output_kbps:70.17

rejected_connections:0

sync_full:0

修改后机器A上的9001 输出

[[email protected] redis-node]# redis-cli -p 9001 info  clients

# Clients

connected_clients:4695

client_longest_output_list:0

client_biggest_input_buf:0

blocked_clients:

7.总结:

在redis设置同样而内存使用不同时,应先查看info命令对比正常机器的输出不同,优先关注Stats的输出情况以及本地的redis.log日志

原文地址:https://www.cnblogs.com/ibyte/p/9762261.html

时间: 2024-10-12 02:01:43

Redis主节点内存占用过高的相关文章

CLR Profile解决内存占用过高

CLR Profile解决内存占用过高的问题 炮哥:"嘿,哥们,忙啥呢,电脑卡成这逼样." 勇哥:"在用CLR Profile工具分析下FlexiPrint的内存占用情况." 炮哥:“哎哟,不错啊,玩高级的了.” 勇哥:“也没有啊,就是发现点击查询按钮查询数据时,如果数据量一大的话,内存上上升了好几个M,所以第一感觉就不太正常.正好以前也了解过CLR Profile,但一直没怎么具休的用过,这次正好拿来研究研究.” 炮哥:“Nice job,要向你学习,能够主动发现

cocos2dx 中切换场景内存占用过高的处理

cocos2dx 中切换场景内存占用过高的处理 1.运行场景: CCScene *pScene = HelloWorld::scene(); pDirector->runWithScene(pScene); 2.替换场景: (1) CCScene *pScene=SceneTestScene::scene(); CCDirector::sharedDirector()->replaceScene(pScene); (2) CCScene *pScene=SceneTestScene::scen

UIWebView内存占用过高、崩溃、内存溢出

UIWebView内存占用过高.崩溃.内存溢出,有需要的朋友可以参考下. 项目当中模拟器上运行UIWebView读取本地杂志,没问题,真机测试经常内存溢出崩溃. 查了资料因为Html里的js 导致的内存泄漏,每次打开一个连接就会把"WebKitCacheModelPreferenceKey"设置成1. UIWebView 增加 - (void)webViewDidFinishLoad:(UIWebView *)webView { [[NSUserDefaults standardUse

ITM_win_agentCPU内存占用较高

这个问题一般出现在ITM623fp1上,win agent监控的OS是win2003 而且这个问题一般会通过省级ITM来解决 以下是一些通用的解决方法 Kntcma.exe占用CPU 100%  Kntcma.exe占用内存资源较高 server安装ITM 623FP2补丁 agent安装6.2.3.2-TIV-ITM_WIN-IF0001补丁 在KNTENV文件中设置 NT_LOG_THROTTLE=1 和 NT_LOG_APPEND_XML_DATA=0 - 重建性能技术器 cd\windo

(转)aix非计算内存 占用过高 案例一则

两台小型机组成的RAC环境,在用topas查看资源使用情况时,发现一台机器的非计算内存占用过高: MEMORY Real,MB 40959 %Comp 71.6 %Noncomp 20.4 %Client 20.4 而另外一台机器的%Noncomp 只有2.4 这主要是jfs2文件系统的cache,可以用svmon -S的输出来看,是哪些文件: [email protected]/#svmon -S Vsid Esid Type Description PSize Inuse Pin Pgsp

rabbitmq binary/other_system内存占用很高

最近有台服务器的MQ应用占用内存比较偏高,如下: 但是看控制台本身内存中消息积压并不多, 查看rabbtmqctl发现,binary data和other data占据了绝大部分的内存,如下: {memory, [{total,124441400}, {connection_readers,5548680}, {connection_writers,605560}, {connection_channels,2798608}, {connection_other,7775480}, {queue

linux内存占用过高原因

今天服务器装了个lnmp环境,看了下那个探针, 发现内存占用97%,瞬间吓尿了. google了半天才发现,一般的解释是Linux系统下有一种思想,内存不用白不用,占用了就不释放,听上去有点道理,但如果我一定要知道应用程序还能有多少内存可用呢? Linux下查看内存还有一个更方便的命令,free: [[email protected] ~]# free -m              total       used       free     shared    buffers     ca

linux内存占用过高

top top -H -p 28857jstack 28857 > a.txtjstack -F pid 如果是web应用,可以继续打印线程的堆栈信息+++++++++ strace -p 24167 通过这3步基本可以找出什么原因导致java进程占用那么高CPU资源. 将需要的线程ID转换为16进制格式:printf "%x\n" 2967973ef最后打印线程的堆栈信息:jstack 29679|grep 73ef -A 30

内存 占用过高

故障特点: 服务项目停止,访问不了 发现问题登录上服务器,登录过程中很慢. 登录上df -Th 查看磁盘空间发现是磁盘满了,du -sh --exclude /proc /* |sort -h 看到是 /var/ 日志文件的过多引起的磁盘占用过多 清理磁盘,重新启动项目. 过了会儿 开发过来说项目没有启动看看是怎么回事, 启动完成是可以的 只能上去查找原因 登录时发现登录不上,等了好长时间才登录上去 因为根磁盘满的情况下是没有这么严重的,重启后再登录出现的问题 所以上来后 先 ps aux|gr