redis状态监控与性能调优

1、redis-benchmark

redis基准信息,redis服务器性能检测

例如:

检测redis服务器性能,本机6379端口的实例,100个并发连接,100000个请求

redis-benchmark -h localhost -p 6379 -c 100 -n 100000 

[[email protected] ~]# redis-benchmark -h localhost -p 6379 -c 100 -n 100000
====== PING_INLINE ======
  100000 requests completed in 1.29 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1

81.97% <= 1 milliseconds
97.69% <= 2 milliseconds
99.79% <= 3 milliseconds
99.94% <= 4 milliseconds
99.97% <= 5 milliseconds
100.00% <= 5 milliseconds
77639.75 requests per second

====== PING_BULK ======
  100000 requests completed in 1.49 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1

73.04% <= 1 milliseconds
97.46% <= 2 milliseconds
99.62% <= 3 milliseconds
99.97% <= 4 milliseconds
100.00% <= 5 milliseconds
100.00% <= 5 milliseconds
67204.30 requests per second

====== SET ======
  100000 requests completed in 1.30 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1

81.09% <= 1 milliseconds
97.16% <= 2 milliseconds
99.43% <= 3 milliseconds
99.75% <= 4 milliseconds
99.80% <= 5 milliseconds
99.82% <= 7 milliseconds
99.83% <= 8 milliseconds
99.85% <= 9 milliseconds
99.87% <= 10 milliseconds
99.89% <= 11 milliseconds
99.89% <= 12 milliseconds
99.90% <= 13 milliseconds
99.90% <= 14 milliseconds
99.90% <= 15 milliseconds
99.91% <= 16 milliseconds
99.93% <= 17 milliseconds
99.94% <= 18 milliseconds
99.95% <= 19 milliseconds
99.96% <= 20 milliseconds
99.98% <= 21 milliseconds
99.99% <= 22 milliseconds
100.00% <= 23 milliseconds
100.00% <= 23 milliseconds
76687.12 requests per second

====== GET ======
  100000 requests completed in 1.91 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1

49.74% <= 1 milliseconds
93.92% <= 2 milliseconds
99.37% <= 3 milliseconds
99.95% <= 4 milliseconds
99.97% <= 5 milliseconds
99.98% <= 6 milliseconds
100.00% <= 6 milliseconds
52273.91 requests per second

====== INCR ======
  100000 requests completed in 1.60 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1

66.32% <= 1 milliseconds
96.55% <= 2 milliseconds
99.61% <= 3 milliseconds
99.96% <= 4 milliseconds
100.00% <= 5 milliseconds
62344.14 requests per second

====== LPUSH ======
  100000 requests completed in 1.27 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1

73.84% <= 1 milliseconds
95.61% <= 2 milliseconds
99.36% <= 3 milliseconds
99.96% <= 4 milliseconds
99.99% <= 5 milliseconds
100.00% <= 5 milliseconds
78492.93 requests per second

====== RPUSH ======
  100000 requests completed in 1.31 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1

80.47% <= 1 milliseconds
96.93% <= 2 milliseconds
99.56% <= 3 milliseconds
99.98% <= 4 milliseconds
100.00% <= 5 milliseconds
100.00% <= 5 milliseconds
76103.50 requests per second

====== LPOP ======
  100000 requests completed in 1.30 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1

74.91% <= 1 milliseconds
95.50% <= 2 milliseconds
99.29% <= 3 milliseconds
99.95% <= 4 milliseconds
100.00% <= 5 milliseconds
100.00% <= 5 milliseconds
77101.00 requests per second

====== RPOP ======
  100000 requests completed in 1.40 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1

77.99% <= 1 milliseconds
97.07% <= 2 milliseconds
99.61% <= 3 milliseconds
99.97% <= 4 milliseconds
99.98% <= 5 milliseconds
100.00% <= 6 milliseconds
100.00% <= 6 milliseconds
71377.59 requests per second

====== SADD ======
  100000 requests completed in 1.32 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1

80.83% <= 1 milliseconds
97.14% <= 2 milliseconds
99.57% <= 3 milliseconds
99.95% <= 4 milliseconds
100.00% <= 5 milliseconds
100.00% <= 5 milliseconds
75757.57 requests per second

====== HSET ======
  100000 requests completed in 1.30 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1

80.25% <= 1 milliseconds
96.83% <= 2 milliseconds
99.49% <= 3 milliseconds
99.97% <= 4 milliseconds
100.00% <= 4 milliseconds
76923.08 requests per second

====== SPOP ======
  100000 requests completed in 1.48 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1

73.97% <= 1 milliseconds
96.91% <= 2 milliseconds
99.55% <= 3 milliseconds
99.96% <= 4 milliseconds
100.00% <= 5 milliseconds
100.00% <= 5 milliseconds
67567.57 requests per second

====== LPUSH (needed to benchmark LRANGE) ======
  100000 requests completed in 1.35 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1

71.03% <= 1 milliseconds
95.36% <= 2 milliseconds
99.29% <= 3 milliseconds
99.97% <= 4 milliseconds
100.00% <= 5 milliseconds
100.00% <= 5 milliseconds
73909.83 requests per second

====== LRANGE_100 (first 100 elements) ======
  100000 requests completed in 2.91 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1

14.30% <= 1 milliseconds
80.30% <= 2 milliseconds
94.42% <= 3 milliseconds
96.88% <= 4 milliseconds
98.34% <= 5 milliseconds
99.39% <= 6 milliseconds
99.78% <= 7 milliseconds
99.93% <= 8 milliseconds
99.97% <= 9 milliseconds
99.98% <= 10 milliseconds
100.00% <= 11 milliseconds
100.00% <= 11 milliseconds
34317.09 requests per second

====== LRANGE_300 (first 300 elements) ======
  100000 requests completed in 5.88 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1

0.00% <= 2 milliseconds
85.83% <= 3 milliseconds
94.17% <= 4 milliseconds
96.10% <= 5 milliseconds
97.90% <= 6 milliseconds
98.68% <= 7 milliseconds
98.70% <= 8 milliseconds
99.30% <= 9 milliseconds
99.49% <= 10 milliseconds
99.76% <= 11 milliseconds
99.79% <= 12 milliseconds
99.83% <= 13 milliseconds
99.85% <= 14 milliseconds
99.87% <= 15 milliseconds
99.89% <= 16 milliseconds
99.91% <= 17 milliseconds
99.92% <= 19 milliseconds
99.93% <= 20 milliseconds
99.94% <= 21 milliseconds
99.95% <= 22 milliseconds
99.96% <= 23 milliseconds
99.97% <= 24 milliseconds
99.99% <= 25 milliseconds
99.99% <= 26 milliseconds
100.00% <= 27 milliseconds
17006.80 requests per second

====== LRANGE_500 (first 450 elements) ======
  100000 requests completed in 8.16 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1

0.00% <= 2 milliseconds
0.01% <= 3 milliseconds
80.98% <= 4 milliseconds
90.89% <= 5 milliseconds
95.60% <= 6 milliseconds
97.20% <= 7 milliseconds
98.23% <= 8 milliseconds
98.53% <= 9 milliseconds
99.06% <= 10 milliseconds
99.09% <= 11 milliseconds
99.46% <= 12 milliseconds
99.53% <= 13 milliseconds
99.65% <= 14 milliseconds
99.75% <= 15 milliseconds
99.79% <= 16 milliseconds
99.81% <= 17 milliseconds
99.82% <= 18 milliseconds
99.84% <= 19 milliseconds
99.85% <= 20 milliseconds
99.86% <= 21 milliseconds
99.87% <= 22 milliseconds
99.88% <= 23 milliseconds
99.89% <= 24 milliseconds
99.90% <= 25 milliseconds
99.91% <= 26 milliseconds
99.93% <= 27 milliseconds
99.93% <= 28 milliseconds
99.94% <= 29 milliseconds
99.95% <= 30 milliseconds
99.96% <= 31 milliseconds
99.98% <= 32 milliseconds
99.98% <= 33 milliseconds
99.99% <= 34 milliseconds
99.99% <= 35 milliseconds
100.00% <= 36 milliseconds
100.00% <= 36 milliseconds
12260.91 requests per second

====== LRANGE_600 (first 600 elements) ======
  100000 requests completed in 10.15 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1

0.00% <= 3 milliseconds
0.01% <= 4 milliseconds
84.84% <= 5 milliseconds
93.41% <= 6 milliseconds
96.43% <= 7 milliseconds
97.71% <= 8 milliseconds
97.75% <= 9 milliseconds
98.32% <= 10 milliseconds
98.79% <= 11 milliseconds
99.19% <= 12 milliseconds
99.22% <= 13 milliseconds
99.25% <= 14 milliseconds
99.48% <= 15 milliseconds
99.56% <= 16 milliseconds
99.60% <= 17 milliseconds
99.68% <= 18 milliseconds
99.74% <= 19 milliseconds
99.77% <= 20 milliseconds
99.79% <= 21 milliseconds
99.82% <= 22 milliseconds
99.83% <= 23 milliseconds
99.85% <= 24 milliseconds
99.86% <= 25 milliseconds
99.86% <= 26 milliseconds
99.87% <= 27 milliseconds
99.88% <= 28 milliseconds
99.89% <= 29 milliseconds
99.90% <= 30 milliseconds
99.90% <= 31 milliseconds
99.91% <= 32 milliseconds
99.91% <= 33 milliseconds
99.92% <= 34 milliseconds
99.94% <= 35 milliseconds
99.95% <= 36 milliseconds
99.95% <= 37 milliseconds
99.96% <= 38 milliseconds
99.96% <= 39 milliseconds
99.96% <= 40 milliseconds
99.97% <= 41 milliseconds
99.98% <= 42 milliseconds
99.98% <= 43 milliseconds
99.99% <= 44 milliseconds
99.99% <= 45 milliseconds
99.99% <= 46 milliseconds
100.00% <= 47 milliseconds
100.00% <= 47 milliseconds
9851.25 requests per second

====== MSET (10 keys) ======
  100000 requests completed in 1.89 seconds
  100 parallel clients
  3 bytes payload
  keep alive: 1

0.00% <= 1 milliseconds
75.00% <= 2 milliseconds
89.85% <= 3 milliseconds
95.38% <= 4 milliseconds
98.52% <= 5 milliseconds
99.34% <= 6 milliseconds
99.60% <= 7 milliseconds
99.83% <= 8 milliseconds
99.98% <= 9 milliseconds
100.00% <= 9 milliseconds
52994.17 requests per second

[[email protected]-server ~]# 

2、redis-cli

例1:监控本机6379端口的实例的数据操作,redis的连接及读写操作

redis-cli -h localhost -p 6379 monitor 

先开启一个终端1,用于redis监控

[[email protected] ~]# redis-cli -h localhost -p 6379 monitor
OK
1504689350.635365 [0 127.0.0.1:57996] "COMMAND"
1504689361.944610 [0 127.0.0.1:57996] "set" "a" "1"
1504689369.782029 [0 127.0.0.1:57996] "get" "a"

然后在开启一个redis终端2进行操作

[[email protected] ~]# redis-cli -p 6379
127.0.0.1:6380> set a 1
OK
127.0.0.1:6380> get a
"1"
127.0.0.1:6380> 

可以看到终端2上面进行的数据操作会在终端1上面被记录下来

例2:查询本机redis实例的信息,端口6379

redis-cli -h localhost -p 6379 info 

备注:该命令也可以在redis终端里面进行查询

[[email protected] ~]# redis-cli -h localhost -p 6379 info
# Server
redis_version:3.2.10
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:eae5a0b8746eb6ce
redis_mode:standalone
os:Linux 2.6.32-431.el6.x86_64 x86_64
arch_bits:64
multiplexing_api:epoll
gcc_version:4.4.7
process_id:6003
run_id:0057d03b2e908ee036c2aa1c3531e8aa051d7468
tcp_port:6379
uptime_in_seconds:159221
uptime_in_days:1
hz:10
lru_clock:11517636
executable:/usr/local/redis/bin/redis-server
config_file:/usr/local/redis/conf/redis.conf

# Clients
connected_clients:1
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0

# Memory
used_memory:1828104
used_memory_human:1.74M
used_memory_rss:4050944
used_memory_rss_human:3.86M
used_memory_peak:8439360
used_memory_peak_human:8.05M
total_system_memory:1960443904
total_system_memory_human:1.83G
used_memory_lua:37888
used_memory_lua_human:37.00K
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
mem_fragmentation_ratio:2.22
mem_allocator:jemalloc-4.0.3

# Persistence
loading:0
rdb_changes_since_last_save:0
rdb_bgsave_in_progress:0
rdb_last_save_time:1504689256
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:0
rdb_current_bgsave_time_sec:-1
aof_enabled:0
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok

# Stats
total_connections_received:3603
total_commands_processed:3600007
instantaneous_ops_per_sec:0
total_net_input_bytes:192800186
total_net_output_bytes:2634476722
instantaneous_input_kbps:0.00
instantaneous_output_kbps:0.00
rejected_connections:0
sync_full:0
sync_partial_ok:0
sync_partial_err:0
expired_keys:0
evicted_keys:0
keyspace_hits:1000003
keyspace_misses:0
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:408
migrate_cached_sockets:0

# Replication
role:master
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

# CPU
used_cpu_sys:99.45
used_cpu_user:108.88
used_cpu_sys_children:0.01
used_cpu_user_children:0.01

# Cluster
cluster_enabled:0

# Keyspace
db0:keys=7,expires=0,avg_ttl=0
[[email protected]-server ~]# 
时间: 2024-08-09 02:00:00

redis状态监控与性能调优的相关文章

mysql监控、性能调优及三范式理解

原文:mysql监控.性能调优及三范式理解 1监控 工具:sp on mysql     sp系列可监控各种数据库 2调优 2.1 DB层操作与调优 2.1.1.开启慢查询 在My.cnf文件中添加如下内容(如果不知道my.cnf的路径可使用find / -name my.cnf进行查找): 在mysqld下添加 Log_slow_queries = ON  作用:开启慢查询服务 Log-slow-queries = /var/log/slowqueries.log 作用:慢查询日志存储路径.

tomcat完结篇,JVM状态监控与内存调优。

本篇合适对tomcat和JVM有一定了解的朋友. 常用的内置变量介绍: CATALINA_BASE  //用于设定可以具有写权限或者自定义部分的文件存放位置,适用场景,需要在一节点上启动多个tomcat实例,就可以定义多个CATALINA_BASE. CATALINA_OPTS //定义JVM的运行属性 JAVA_OPTS  //定义多个JVM相同运行属性. JAVA_HOME  //用于设定java或JDK运行时候的本地位置. JRE_HOME   //这是一个JAVA_HOME的别名. 了解

Redis性能调优

Redis性能调优 尽管Redis是一个非常快速的内存数据存储媒介,也并不代表Redis不会产生性能问题.前文中提到过,Redis采用单线程模型,所有的命令都是由一个线程串行执行的,所以当某个命令执行耗时较长时,会拖慢其后的所有命令,这使得Redis对每个任务的执行效率更加敏感. 针对Redis的性能优化,主要从下面几个层面入手: 最初的也是最重要的,确保没有让Redis执行耗时长的命令 使用pipelining将连续执行的命令组合执行 操作系统的Transparent huge pages功能

Redis基础、高级特性与性能调优

本文将从Redis的基本特性入手,通过讲述Redis的数据结构和主要命令对Redis的基本能力进行直观介绍.之后概览Redis提供的高级能力,并在部署.维护.性能调优等多个方面进行更深入的介绍和指导.本文适合使用Redis的普通开发人员,以及对Redis进行选型.架构设计和性能调优的架构设计人员. 目录 概述 Redis的数据结构和相关常用命令 数据持久化 内存管理与数据淘汰机制 Pipelining 事务与Scripting Redis性能调优 主从复制与集群分片 Redis Java客户端的

Redis 基础、高级特性与性能调优

本文将从Redis的基本特性入手,通过讲述Redis的数据结构和主要命令对Redis的基本能力进行直观介绍.之后概览Redis提供的高级能力,并在部署.维护.性能调优等多个方面进行更深入的介绍和指导. 本文适合使用Redis的普通开发人员,以及对Redis进行选型.架构设计和性能调优的架构设计人员. 目录 概述 Redis的数据结构和相关常用命令 数据持久化 内存管理与数据淘汰机制 Pipelining 事务与Scripting Redis性能调优 主从复制与集群分片 Redis Java客户端

性能测试分析与性能调优诊断--史上最全的服务器性能分析监控调优篇

一个系统或者网站在功能开发完成后一般最终都需要部署到服务器上运行,那么服务器的性能监控和分析就显得非常重要了,选用什么配置的服务器.如何对服务器进行调优.如何从服务器监控中发现程序的性能问题. 如何判断服务器的瓶颈在哪里等 就成为了服务器性能监控和分析时重点需要去解决的问题了. 1     服务器的性能监控和分析 1.1      Linux服务器的性能指标监控和分析 1.1.1       通过vmstat深挖服务器的性能问题 1.1.2       如何通过mpstat 分析服务器的性能指标

MySQL性能调优与架构设计——第 18 章 高可用设计之 MySQL 监控

第 18 章 高可用设计之 MySQL 监控 前言: 一个经过高可用可扩展设计的 MySQL 数据库集群,如果没有一个足够精细足够强大的监控系统,同样可能会让之前在高可用设计方面所做的努力功亏一篑.一个系统,无论如何设计如何维护,都无法完全避免出现异常的可能,监控系统就是根据系统的各项状态的分析,让我们能够尽可能多的提前预知系统可能会出现的异常状况.即使没有及时发现将要发生的异常,也要在异常出现后的第一时间知道系统已经出现异常,否则之前的设计工作很可能就白费了. 18.1 监控系统设计 系统监控

MySQL管理之道:性能调优、高可用与监控》迷你书

MySQL管理之道:性能调优.高可用与监控>迷你书 MYSQL5.5.X主要改进 1.默认使用innodb存储引擎2.充分利用CPU多核处理能力3.提高刷写脏页数量和合并插入数量,改善I/O4.让innodb_buffer_pool缓冲池中的热数据存活更久,污染问题5.innodb数据恢复时间加快6.innodb同时支持多个buffer pool实例7.可关闭自适应哈希索引,semaphores信号量8.在innodb中可选择使用内存分配程序:TCMalloc 谷歌开发9.提高默认innodb线

Redis性能调优:保存SNAPSHOT对性能的影响

前一段时间,开发环境反馈,Redis服务器访问非常慢,每个请求要数秒时间,重启之后2~3天又会这样. 我查看了一下Linux的性能,没有什么问题.通过 # redis-cli --latency 发现访问Redis确实很慢,执行info要几秒时间.里面有个参数已连接的客户端几万个,通过 Redis>client list 查看到很多client的age都很大,一直没有释放.于是怀疑是不是和这个有关,因为版本是2.8.6,无法通过client一次性kill掉所有的连接,只能写一个程序,一个一个地k