Redis开发运维的陷阱及避坑指南

本文涉及的产品
云数据库 Redis 版,社区版 2GB
推荐场景:
搭建游戏排行榜
简介:

Redis开发运维的陷阱及避坑指南

Linux 配置优化
我们在使用 Redis 过程中,可能更多的关注 Redis 本身的一些配置优化,如 AOF、RDB 配置、数据结构配置优化等。但是很少关心 Redis 的载体,服务器的优化。而这往往为我们的项目运行带来灾难性的打击。因此服务器优化也是必不可少的

内存分配控制
Redis启动时,可能会出现下面的日志

WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.

overcommit 是 Linux 的一种内存处理机制:Linux 对绝大多数内存申请都会回复 yes,以便运行更多的程序。因为申请内存后,并不会马上使用内存。这种机制就是 overcommit 。

而 overcommit_memory 是用来设置内存分配策略的,有三种取值

值 含义
0 内核检查是否有足够可用内存,有则通过。没有则申请失败,并返回错误给进程
1 表示内核允许超量使用内存直到用完为止
2 表示内核绝不过量的使用内存
日志中 Background save 指的是 bgsave 和 bgrewriteaof 。根据操作系统的配置,如果 overcommit_memory 设置为 0 则可能会造成内存申请失败而导致后台持久化失败。因此 Redis 建议将这个值设置为 1 是为了 fork 操作在低内存下也能执行成功。

设置方法
通过命令修改,立即生效。重启后会失效

sysctl vm.overcommit_memory=1
再将改动写入系统配置文件,使其永久有效

echo "vm.overcommit_memory=1" >> /etc/sysctl.conf

建议
采用 Redis 建议的配置是为了在极端情况下 Linux 可以挤出来一些内存供 Redis 备份,但是更建议优先配置好 maxmemory ,给机器留 20%~30% 的空闲内存

硬盘虚拟内存
swap 是指当物理内存不足时,拿出部分硬盘空间当 SWAP 分区(虚拟成内存)使用。我们都知道硬盘的读写速度相对于内存实在是太鸡肋,对于高并发、高吞吐的应用来说,磁盘IO通长会成为系统瓶颈。Linux 系统中 swappiness 的值控制操作系统使用 swap 的倾向程度。

查看内核版本:

uname -sr
值 说明
0 内核版本 3.5 及以上 宁愿使用 OOM Killer 也不使用 SWAP;内核版本 3.4 及更早则反之
1 内核版本 3.5 及以上 宁愿使用 OOM Killer 也不使用 SWAP
60 默认值

主动使用 SWAP
PS:OOM Killer 是指当 Linux 发现操作系统内存不足时,主动杀死一些非内核进程的操作

设置方法
echo {value} > /proc/sys/vm/swappiness

echo vm.swappiness={value} >> etc/sysctl.conf

监控swap
查看 Swap 的总体情况
free -m

最后一行即展示了 Swap 的使用情况,一共 2047 Mb,以使用 0 Mb,空闲 2047 Mb

实时查看 Swap 的使用

参数 si 表示 swap in ,so 表示 swap out 在我的机器上都是 0 表示没有使用交换

查看指定进程的 Swap 情况
通过 ps -ef |grep redis 查看 Redis 进程号,例如 1621

通过 cat /proc/1621/smaps | grep Swap 命令查看每个内存块 Redis Swap 的使用情况

THP 内存页大小
Redis 启动时可能会看到下面的日志

WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.
提示告诉我们建议修改 Transparent Huge Pages (THP) 的配置,Linux kernel 在 2.6.38 内核增加了 THP 特性,支持大内存页(2MB)分配,默认开启。开启后可加快 fork 子进程的速度,但是 fork 操作后,每个内存页从原来的 4KB 变为 2MB,会大幅加重重写期间父进程内存消耗。同时每次写命令引起的复制内存页单位放大了512倍。会拖慢写操作的执行时间。造成大量的写操作慢查询因此 Redis 日志中建议禁用它。方法如下:

echo never > /sys/kernel/mm/transparent_hugepage/enabled
另外在 /etc/rc.local 中追加

echo never > /sys/kernel/mm/transparent_hugepage/enabled
对于某些发行版本(例如红帽6以上)配置文件不在这个位置(在 /sys/kernel/mm/redhat_transparent_hugepage/enabled),但是 Redis 检查 THP 是写死的此位置,所以虽然这么修改后 Redis 不报警然而实际是没有作用的,需要注意。应该改动对应位置的值

使用NTP 同步时间
在集群或哨兵环境中,多台服务器使用相同的网络时间协议同步时间能更方便的阅读日志,排查问题

可以设置定时任务同步时间

crontab -u //设定某个用户的cron服务
crontab -l //列出某个用户cron服务的详细内容
crontab -r //删除某个用户的cron服务
crontab -e //编辑某个用户的cron服务
crontab -i //打印提示,输入yes等确认信息
添加每小时执行一次的任务

0 /usr/sbin/ntpdate cn.pool.ntp.org > dev/null 2>&1

最大连接数限制
通过 ulimit -a 命令查看和设置当前用户进程的资源数,其中包含 open files 参数,是单个用户同时打开的最大文件描述符个数。虽然 Redis 中可以配置最大的客户端连接数(默认 10000) 。Redis 内部最多使用 32 个文件描述符。当 open files = 4096 时,Redis 最大提供 4096-32=4064 个连接。因为它不能突破操作系统的限制。如果需要,使用如下命令修改:

ulimit -Sn {max-open-files}

TCP backlog
tcp backlog 配置的是 tcp 握手时候的队列大小。如果该值过小。会导致高并发场景下部分连接第三次握手ACK被丢弃。关于 backlog

The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
Redis 启动时,会告诉我们系统配置中该值是 128,而 Redis 511。这个 511 是没用的,因为系统比这个小。需要修改系统 backlog 的值

echo 511 > /proc/sys/net/core/somaxconn
参考文献:

《Redis开发与运维》 --- 付 磊 张益军

原文地址https://www.cnblogs.com/keatsCoder/p/12790746.html

相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore     ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库 ECS 实例和一台目标数据库 RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
相关文章
|
1月前
|
人工智能 运维 监控
构建高性能微服务架构:现代后端开发的挑战与策略构建高效自动化运维系统的关键策略
【2月更文挑战第30天】 随着企业应用的复杂性增加,传统的单体应用架构已经难以满足快速迭代和高可用性的需求。微服务架构作为解决方案,以其服务的细粒度、独立性和弹性而受到青睐。本文将深入探讨如何构建一个高性能的微服务系统,包括关键的设计原则、常用的技术栈选择以及性能优化的最佳实践。我们将分析微服务在处理分布式事务、数据一致性以及服务发现等方面的挑战,并提出相应的解决策略。通过实例分析和案例研究,我们的目标是为后端开发人员提供一套实用的指南,帮助他们构建出既能快速响应市场变化,又能保持高效率和稳定性的微服务系统。 【2月更文挑战第30天】随着信息技术的飞速发展,企业对于信息系统的稳定性和效率要求
|
5天前
|
人工智能 前端开发 Java
Java语言开发的AI智慧导诊系统源码springboot+redis 3D互联网智导诊系统源码
智慧导诊解决盲目就诊问题,减轻分诊工作压力。降低挂错号比例,优化就诊流程,有效提高线上线下医疗机构接诊效率。可通过人体画像选择症状部位,了解对应病症信息和推荐就医科室。
30 10
|
10天前
|
NoSQL 关系型数据库 MySQL
开发者福音:用IDEA和Iedis2加速Redis开发与调试
开发者福音:用IDEA和Iedis2加速Redis开发与调试
24 0
开发者福音:用IDEA和Iedis2加速Redis开发与调试
|
12天前
|
运维 NoSQL 算法
Java开发-深入理解Redis Cluster的工作原理
综上所述,Redis Cluster通过数据分片、节点发现、主从复制、数据迁移、故障检测和客户端路由等机制,实现了一个分布式的、高可用的Redis解决方案。它允许数据分布在多个节点上,提供了自动故障转移和读写分离的功能,适用于需要大规模、高性能、高可用性的应用场景。
16 0
|
1月前
|
人工智能 JSON 运维
AI大模型运维开发探索第三篇:深入浅出运维智能体
大模型出现伊始,我们就在SREWorks开源社区征集相关的实验案例。玦离同学提供了面向大数据HDFS集群的智能体案例,非常好地完成了运维诊断的目标。于是基于这一系列的实验和探索。本文详细介绍智能体在运维诊断中的应用探索。
|
2月前
|
Kubernetes Linux 开发工具
容器开发运维人员的 Linux 操作机配置优化建议
容器开发运维人员的 Linux 操作机配置优化建议
|
3月前
|
消息中间件 存储 NoSQL
Redis开发最佳实践
Redis开发最佳实践
62 0
|
3月前
|
NoSQL 关系型数据库 MySQL
mysql与redis在java开发过程中的数据一致性问题
mysql与redis在java开发过程中的数据一致性问题
42 4
|
4月前
|
缓存 NoSQL Java
SSM之spring注解式缓存redis->redis整合,redis的注解式开发及应用场景,redis的击穿穿透雪崩
SSM之spring注解式缓存redis->redis整合,redis的注解式开发及应用场景,redis的击穿穿透雪崩
48 0
|
4月前
|
缓存 NoSQL Java
Redis-----SSM整合redis及redis的注解式开发以及redis的击穿,穿透,雪崩三种解决方案
Redis-----SSM整合redis及redis的注解式开发以及redis的击穿,穿透,雪崩三种解决方案
38 1