当前位置:   article > 正文

Redis 运维 三_redis学习三(运维指南)

redis学习三(运维指南)

一、Redis监控

1.参考地址

http://www.redis.cn/commands/info.html
  • 1

2.内容详解

server相关

redis_version: Redis 服务器版本
redis_git_sha1: Git SHA1
redis_git_dirty: Git dirty flag
redis_build_id: 构建ID
redis_mode: 服务器模式(standalone,sentinel或者cluster)
os: Redis 服务器的宿主操作系统
arch_bits: 架构(3264 位)
multiplexing_api: Redis 所使用的事件处理机制
atomicvar_api: Redis使用的Atomicvar API
gcc_version: 编译 Redis 时所使用的 GCC 版本
process_id: 服务器进程的 PID
run_id: Redis 服务器的随机标识符(用于 Sentinel 和集群)
tcp_port: TCP/IP 监听端口
uptime_in_seconds: 自 Redis 服务器启动以来,经过的秒数
uptime_in_days: 自 Redis 服务器启动以来,经过的天数
hz: 服务器的频率设置
lru_clock: 以分钟为单位进行自增的时钟,用于 LRU 管理
executable: 服务器的可执行文件路径
config_file: 配置文件路径
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19

client相关

connected_clients: 已连接客户端的数量(不包括通过从属服务器连接的客户端)
client_longest_output_list: 当前连接的客户端当中,最长的输出列表
client_biggest_input_buf: 当前连接的客户端当中,最大输入缓存
blocked_clients: 正在等待阻塞命令(BLPOPBRPOPBRPOPLPUSH)的客户端的数量
  • 1
  • 2
  • 3
  • 4

memory相关

used_memory: 由 Redis 分配器分配的内存总量,以字节(byte)为单位
used_memory_human: 以人类可读的格式返回 Redis 分配的内存总量
used_memory_rss: 从操作系统的角度,返回 Redis 已分配的内存总量(俗称常驻集大小)。这个值和 top 、 ps 等命令的输出一致。
used_memory_peak: Redis 的内存消耗峰值(以字节为单位)
used_memory_peak_human: 以人类可读的格式返回 Redis 的内存消耗峰值
used_memory_peak_perc: 使用内存占峰值内存的百分比
used_memory_overhead: 服务器为管理其内部数据结构而分配的所有开销的总和(以字节为单位)
used_memory_startup: Redis在启动时消耗的初始内存大小(以字节为单位)
used_memory_dataset: 以字节为单位的数据集大小(used_memory减去used_memory_overhead)
used_memory_dataset_perc: used_memory_dataset占净内存使用量的百分比(used_memory减去used_memory_startup)
total_system_memory: Redis主机具有的内存总量
total_system_memory_human: 以人类可读的格式返回 Redis主机具有的内存总量
used_memory_lua: Lua 引擎所使用的内存大小(以字节为单位)
used_memory_lua_human: 以人类可读的格式返回 Lua 引擎所使用的内存大小
maxmemory: maxmemory配置指令的值
maxmemory_human: 以人类可读的格式返回 maxmemory配置指令的值
maxmemory_policy: maxmemory-policy配置指令的值
mem_fragmentation_ratio: used_memory_rss 和 used_memory 之间的比率
mem_allocator: 在编译时指定的, Redis 所使用的内存分配器。可以是 libc 、 jemalloc 或者 tcmalloc 。
active_defrag_running: 指示活动碎片整理是否处于活动状态的标志
lazyfree_pending_objects: 等待释放的对象数(由于使用ASYNC选项调用UNLINKFLUSHDBFLUSHALL)
在理想情况下, used_memory_rss 的值应该只比 used_memory 稍微高一点儿。
当 rss > used ,且两者的值相差较大时,表示存在(内部或外部的)内存碎片。
内存碎片的比率可以通过 mem_fragmentation_ratio 的值看出。
当 used > rss 时,表示 Redis 的部分内存被操作系统换出到交换空间了,在这种情况下,操作可能会产生明显的延迟。
由于Redis无法控制其分配的内存如何映射到内存页,因此常住内存(used_memory_rss)很高通常是内存使用量激增的结果。
当 Redis 释放内存时,内存将返回给分配器,分配器可能会,也可能不会,将内存返还给操作系统。
如果 Redis 释放了内存,却没有将内存返还给操作系统,那么 used_memory 的值可能和操作系统显示的 Redis 内存占用并不一致。
查看 used_memory_peak 的值可以验证这种情况是否发生。
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29

持久化相关

loading: 指示转储文件(dump)的加载是否正在进行的标志
rdb_changes_since_last_save: 自上次转储以来的更改次数
rdb_bgsave_in_progress: 指示RDB文件是否正在保存的标志
rdb_last_save_time: 上次成功保存RDB的基于纪年的时间戳
rdb_last_bgsave_status: 上次RDB保存操作的状态
rdb_last_bgsave_time_sec: 上次RDB保存操作的持续时间(以秒为单位)
rdb_current_bgsave_time_sec: 正在进行的RDB保存操作的持续时间(如果有)
rdb_last_cow_size: 上次RDB保存操作期间copy-on-write分配的字节大小
aof_enabled: 表示AOF记录已激活的标志
aof_rewrite_in_progress: 表示AOF重写操作正在进行的标志
aof_rewrite_scheduled: 表示一旦进行中的RDB保存操作完成,就会安排进行AOF重写操作的标志
aof_last_rewrite_time_sec: 上次AOF重写操作的持续时间,以秒为单位
aof_current_rewrite_time_sec: 正在进行的AOF重写操作的持续时间(如果有)
aof_last_bgrewrite_status: 上次AOF重写操作的状态
aof_last_write_status: 上一次AOF写入操作的状态
aof_last_cow_size: 上次AOF重写操作期间copy-on-write分配的字节大
aof_current_size: 当前的AOF文件大小
aof_base_size: 上次启动或重写时的AOF文件大小
aof_pending_rewrite: 指示AOF重写操作是否会在当前RDB保存操作完成后立即执行的标志。
aof_buffer_length: AOF缓冲区大小
aof_rewrite_buffer_length: AOF重写缓冲区大小
aof_pending_bio_fsync: 在后台IO队列中等待fsync处理的任务数
aof_delayed_fsync: 延迟fsync计数器
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23

正在加载的操作

loading_start_time: 加载操作的开始时间(基于纪元的时间戳)
loading_total_bytes: 文件总大小
loading_loaded_bytes: 已经加载的字节数
loading_loaded_perc: 已经加载的百分比
loading_eta_seconds: 预计加载完成所需的剩余秒数
  • 1
  • 2
  • 3
  • 4
  • 5

stats相关

total_connections_received: 服务器接受的连接总数
total_commands_processed: 服务器处理的命令总数
instantaneous_ops_per_sec: 每秒处理的命令数
rejected_connections: 由于maxclients限制而拒绝的连接数
expired_keys: key到期事件的总数
evicted_keys: 由于maxmemory限制而导致被驱逐的key的数量
keyspace_hits: 在主字典中成功查找到key的次数
keyspace_misses: 在主字典中查找key失败的次数
pubsub_channels: 拥有客户端订阅的全局pub/sub通道数
pubsub_patterns: 拥有客户端订阅的全局pub/sub模式数
latest_fork_usec: 最新fork操作的持续时间,以微秒为单位
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11

replication相关

role: 如果实例不是任何节点的从节点,则值是”master”,如果实例从某个节点同步数据,则是”slave”。 请注意,一个从节点可以是另一个从节点的主节点(菊花链)。
如果实例是从节点,则会提供以下这些额外字段:

master_host: 主节点的Host名称或IP地址
master_port: 主节点监听的TCP端口
master_link_status: 连接状态(up或者down)
master_last_io_seconds_ago: 自上次与主节点交互以来,经过的秒数
master_sync_in_progress: 指示主节点正在与从节点同步
如果SYNC操作正在进行,则会提供以下这些字段:

master_sync_left_bytes: 同步完成前剩余的字节数
master_sync_last_io_seconds_ago:SYNC操作期间自上次传输IO以来的秒数
如果主从节点之间的连接断开了,则会提供一个额外的字段:

master_link_down_since_seconds: 自连接断开以来,经过的秒数
以下字段将始终提供:

connected_slaves: 已连接的从节点数
对每个从节点,将会添加以下行:

slaveXXX: id,地址,端口号,状态
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21

CPU相关

used_cpu_sys: 由Redis服务器消耗的系统CPU
used_cpu_user: 由Redis服务器消耗的用户CPU
used_cpu_sys_children: 由后台进程消耗的系统CPU
used_cpu_user_children: 由后台进程消耗的用户CPU
  • 1
  • 2
  • 3
  • 4

3.zabbix参考配置

cat >/etc/zabbix/zabbix_agentd.d/redis.conf <<'EOF'
UserParameter=redis_info[*],redis-cli info|grep -w "$1"|sed -r 's#^.*:##g'
EOF
  • 1
  • 2
  • 3

二、Redis常用运维工具

1.使用第三方工具迁移-只适合4.x之前的版本

需求背景

刚切换到redis集群的时候肯定会面临数据导入的问题,所以这里推荐使用redis-migrate-tool工具来导入单节点数据到集群里
  • 1

官方地址:

http://www.oschina.net/p/redis-migrate-tool
  • 1

安装工具

yum install libtool autoconf automake -y 
cd /opt/
git clone https://github.com/vipshop/redis-migrate-tool.git
cd redis-migrate-tool/
autoreconf -fvi
./configure
make && make install 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

创建配置文件

cat >redis_6379_to_6380.conf <<EOF
[source]
type: single
servers:
- 10.0.0.51:6379
[target]
type: redis cluster
servers:
- 10.0.0.51:6380 
[common]
listen: 0.0.0.0:8888
source_safe: true
EOF
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13

生成测试数据

cat >input_key.sh <<EOF
#!/bin/bash
for i in $(seq 1 1000)
do
  redis-cli -c -h db01 -p 6379 set k_${i} v_${i} && echo "set k_${i} is ok"
done
EOF
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

执行导入命令

redis-migrate-tool -c redis_6379_to_6380.conf 
  • 1

数据校验

redis-migrate-tool -c redis_6379_to_6380.conf -C redis_check
  • 1

2.使用redis-cli数据迁移-适合4.x以后的版本

4.x以前的数据迁移使用第三方工具

https://github.com/vipshop/redis-migrate-tool
  • 1

不加copy参数相当于mv,老数据迁移完成后就删掉了

redis-cli --cluster import 10.0.0.51:6380 --cluster-from 10.0.0.51:6379
  • 1

加了copy参数相当于cp,老数据迁移完成后会保留

redis-cli --cluster import 10.0.0.51:6380 --cluster-from 10.0.0.51:6379 --cluster-copy
  • 1

添加replace参数会覆盖掉同名的数据,如果不添加遇到同名的key会提示冲突,对新集群新增加的数据不受影响

redis-cli --cluster import 10.0.0.51:6380 --cluster-from 10.0.0.51:6379 --cluster-copy --cluster-replace
  • 1

验证迁移期间边写边导会不会影响: 同时开2个终端,一个写入key,

for i in {1..1000};do redis-cli set k_${i} v_${i};sleep 0.2;echo ${i};done
  • 1

一个执行导入命令

redis-cli --cluster import 10.0.0.51:6380 --cluster-copy --cluster-replace --cluster-from  10.0.0.51:6379
  • 1

得出结论:

只会导入当你执行导入命令那一刻时,当前被导入节点的所有数据,类似于快照,对于后面再写入的数据不会更新
  • 1

3.分析key大小

使用redis-cli分析

redis-cli --bigkeys 
redis-cli --memkeys
  • 1
  • 2

使用第三方分析工具:

安装命令

yum install python-pip gcc python-devel -y
cd /opt/
git clone https://github.com/sripathikrishnan/redis-rdb-tools
cd redis-rdb-tools
pip install python-lzf
python setup.py install
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6

生成测试数据

redis-cli set txt $(cat txt.txt)
  • 1

生成rdb文件

redis-cli bgsave
  • 1

使用工具解析RDB文件

cd /data/redis_6379/
rdb -c memory redis_6379.rdb -f redis_6379.rdb.csv
  • 1
  • 2

过滤分析

awk -F"," '{print $4,$3}' redis_6379.rdb.csv |sort -r
  • 1

汇报领导

将结果整理汇报给领导,询问开发这个key是否可以删除
删除之前,最好做次备份
  • 1
  • 2

4.性能测试

redis-benchmark -n 10000 -q
  • 1

5.多实例运维脚本

cat > redis_shell.sh << 'EOF'
#!/bin/bash

USAG(){
    echo "sh $0 {start|stop|restart|login|ps|tail} PORT"
}
if [ "$#" = 1 ]
then
    REDIS_PORT='6379'
elif 
    [ "$#" = 2 -a -z "$(echo "$2"|sed 's#[0-9]##g')" ]
then
    REDIS_PORT="$2"
else
    USAG
    exit 0
fi

REDIS_IP=$(hostname -I|awk '{print $1}')
PATH_DIR=/opt/redis_${REDIS_PORT}/
PATH_CONF=/opt/redis_${REDIS_PORT}/conf/redis_${REDIS_PORT}.conf
PATH_LOG=/opt/redis_${REDIS_PORT}/logs/redis_${REDIS_PORT}.log

CMD_START(){
    redis-server ${PATH_CONF}
}

CMD_SHUTDOWN(){
    redis-cli -c -h ${REDIS_IP} -p ${REDIS_PORT} shutdown
}

CMD_LOGIN(){
    redis-cli -c -h ${REDIS_IP} -p ${REDIS_PORT}
}

CMD_PS(){
    ps -ef|grep redis
}

CMD_TAIL(){
    tail -f ${PATH_LOG}
}

case $1 in
    start)
        CMD_START
        CMD_PS
        ;;
    stop)
        CMD_SHUTDOWN
        CMD_PS
        ;;
    restart)
        CMD_START
        CMD_SHUTDOWN
        CMD_PS
        ;;
    login)
        CMD_LOGIN
        ;;
    ps)
        CMD_PS
        ;;
    tail)
        CMD_TAIL
        ;;
    *)
        USAG
esac
EOF
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70

三、Redis内存管理

1.生产上一定要配置Redis内存限制

maxmemory NG
  • 1

2.内存回收机制

1.noevicition       默认策略,不会删除任务数据,拒绝所有写入操作并返回客户端错误信息,此时只响应读操作
2.volatile-lru      根据LRU算法删除设置了超时属性的key,指导腾出足够空间为止,如果没有可删除的key,则退回到noevicition策略
3.allkeys-lru       根据LRU算法删除key,不管数据有没有设置超时属性
4.allkeys-random    随机删除所有key
5.volatile-random   随机删除过期key
5.volatile-ttl      根据key的ttl,删除最近要过期的key
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6

3.生产上redis限制多大内存

先空出来系统一半内存
48G 一共 
24G 系统
24G redis 
redis先给8G内存 满了之后,分析结果告诉老大和开发,让他们排查一下是否所有的key都是必须的
redis再给到12G内存 满了之后,分析结果告诉老大和开发,让他们排查一下是否所有的key都是必须的
redis再给到16G内存 满了之后,分析结果告诉老大和开发,让他们排查一下是否所有的key都是必须的
等到24G都用完了之后,汇报领导,要考虑买内存了。
等到35G的时候,就要考虑是加内存,还是扩容机器。
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9

4.优化建议

1.专机专用,不要跑其他的服务
2.内存给够,限制内存使用大小
3.使用SSD硬盘
4.网络带宽够大
5.定期分析BigKey
  • 1
  • 2
  • 3
  • 4
  • 5

四、实战-槽位分配错误如何调整

1. 假如是在集群初始化状态下分配错了

解决难度: *
解决方法: 重新初始化

redis-cli -h 10.0.0.51 -p 6380 CLUSTER RESET
redis-cli -h 10.0.0.52 -p 6380 CLUSTER RESET
redis-cli -h 10.0.0.53 -p 6380 CLUSTER RESET
redis-cli -h 10.0.0.51 -p 6381 CLUSTER RESET
redis-cli -h 10.0.0.52 -p 6381 CLUSTER RESET
redis-cli -h 10.0.0.53 -p 6381 CLUSTER RESET

redis-cli -h 10.0.0.51 -p 6380 CLUSTER MEET 10.0.0.52 6380
redis-cli -h 10.0.0.51 -p 6380 CLUSTER MEET 10.0.0.53 6380
redis-cli -h 10.0.0.51 -p 6380 CLUSTER MEET 10.0.0.51 6381
redis-cli -h 10.0.0.51 -p 6380 CLUSTER MEET 10.0.0.52 6381
redis-cli -h 10.0.0.51 -p 6380 CLUSTER MEET 10.0.0.53 6381

redis-cli -h 10.0.0.51 -p 6380 CLUSTER ADDSLOTS {0..5460}
redis-cli -h 10.0.0.52 -p 6380 CLUSTER ADDSLOTS {5461..10921}
redis-cli -h 10.0.0.53 -p 6380 CLUSTER ADDSLOTS {10922..16383}

redis-cli -h 10.0.0.52 -p 6381 CLUSTER NODES
redis-cli -h 10.0.0.52 -p 6381 CLUSTER INFO
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/AllinToyou/article/detail/624656
推荐阅读
相关标签
  

闽ICP备14008679号