`
geeksun
  • 浏览: 952224 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

redis状态与性能监控

 
阅读更多

1.  redis-benchmark是 redis的性能监测工具

Usage: redis-benchmark [-h <host>] [-p <port>] [-c <clients>] [-n <requests]> [-k <boolean>]  
  
-h <hostname>      Server hostname (default 127.0.0.1)  
-p <port>          Server port (default 6379)  
-s <socket>        Server socket (overrides host and port)  
-c <clients>       Number of parallel connections (default 50)  
-n <requests>      Total number of requests (default 10000)  
-d <size>          Data size of SET/GET value in bytes (default 2)  
-k <boolean>       1=keep alive 0=reconnect (default 1)  
-r <keyspacelen>   Use random keys for SET/GET/INCR, random values for SADD  
  Using this option the benchmark will get/set keys  
  in the form mykey_rand:000000012456 instead of constant  
  keys, the <keyspacelen> argument determines the max  
  number of values for the random number. For instance  
  if set to 10 only rand:000000000000 - rand:000000000009  
  range will be allowed.  
-P <numreq>        Pipeline <numreq> requests. Default 1 (no pipeline).  
-q                 Quiet. Just show query/sec values 只显示每秒钟能处理多少请求数结果  
--csv              Output in CSV format  
-l                 Loop. Run the tests forever 永久测试  
-t <tests>         Only run the comma separated list of tests. The test  
                    names are the same as the ones produced as output.  
-I                 Idle mode. Just open N idle connections and wait.  

 

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

 100个并发连接,100000个请求,检测host为localhost端口为6379的redis服务器的性能。

 

====== PING_INLINE ======  
  100000 requests completed in 1.13 seconds  
  100 parallel clients  
  3 bytes payload  
  keep alive: 1  
  
44.60% <= 1 milliseconds  
100.00% <= 1 milliseconds  
88105.73 requests per second  
  
====== PING_BULK ======  
  100000 requests completed in 1.13 seconds  
  100 parallel clients  
  3 bytes payload  
  keep alive: 1  
  
40.55% <= 1 milliseconds  
99.94% <= 2 milliseconds  
100.00% <= 2 milliseconds  
88261.25 requests per second  
  
====== SET ======  
  100000 requests completed in 1.16 seconds  
  100 parallel clients  
  3 bytes payload  
  keep alive: 1  
  
46.39% <= 1 milliseconds  
99.90% <= 2 milliseconds  
99.98% <= 3 milliseconds  
100.00% <= 3 milliseconds  
86058.52 requests per second  
  
====== GET ======  
  100000 requests completed in 1.16 seconds  
  100 parallel clients  
  3 bytes payload  
  keep alive: 1  
  
55.14% <= 1 milliseconds  
99.87% <= 2 milliseconds  
100.00% <= 2 milliseconds  
86058.52 requests per second  
  
====== INCR ======  
  100000 requests completed in 1.16 seconds  
  100 parallel clients  
  3 bytes payload  
  keep alive: 1  
  
51.43% <= 1 milliseconds  
99.70% <= 2 milliseconds  
99.89% <= 3 milliseconds  
99.92% <= 4 milliseconds  
100.00% <= 4 milliseconds  
86505.19 requests per second  
  
====== LPUSH ======  
  100000 requests completed in 1.14 seconds  
  100 parallel clients  
  3 bytes payload  
  keep alive: 1  
  
36.27% <= 1 milliseconds  
99.90% <= 2 milliseconds  
100.00% <= 2 milliseconds  
87565.68 requests per second  
  
====== LPOP ======  
  100000 requests completed in 1.13 seconds  
  100 parallel clients  
  3 bytes payload  
  keep alive: 1  
  
49.68% <= 1 milliseconds  
100.00% <= 1 milliseconds  
88731.15 requests per second  
  
====== SADD ======  
  100000 requests completed in 1.13 seconds  
  100 parallel clients  
  3 bytes payload  
  keep alive: 1  
  
37.29% <= 1 milliseconds  
100.00% <= 1 milliseconds  
88105.73 requests per second  
  
====== SPOP ======  
  100000 requests completed in 1.11 seconds  
  100 parallel clients  
  3 bytes payload  
  keep alive: 1  
  
42.64% <= 1 milliseconds  
99.89% <= 2 milliseconds  
99.90% <= 4 milliseconds  
99.92% <= 5 milliseconds  
100.00% <= 5 milliseconds  
90090.09 requests per second  
  
====== LPUSH (needed to benchmark LRANGE) ======  
  100000 requests completed in 1.14 seconds  
  100 parallel clients  
  3 bytes payload  
  keep alive: 1  
  
46.04% <= 1 milliseconds  
100.00% <= 2 milliseconds  
100.00% <= 2 milliseconds  
87950.75 requests per second  
  
====== LRANGE_100 (first 100 elements) ======  
  100000 requests completed in 4.64 seconds  
  100 parallel clients  
  3 bytes payload  
  keep alive: 1  
  
0.01% <= 1 milliseconds  
2.07% <= 2 milliseconds  
99.65% <= 3 milliseconds  
99.96% <= 4 milliseconds  
100.00% <= 4 milliseconds  
21565.67 requests per second  
  
====== LRANGE_300 (first 300 elements) ======  
  100000 requests completed in 9.80 seconds  
  100 parallel clients  
  3 bytes payload  
  keep alive: 1  
  
0.00% <= 1 milliseconds  
0.01% <= 2 milliseconds  
0.09% <= 3 milliseconds  
8.02% <= 4 milliseconds  
56.57% <= 5 milliseconds  
95.73% <= 6 milliseconds  
99.88% <= 7 milliseconds  
99.97% <= 8 milliseconds  
100.00% <= 9 milliseconds  
10206.16 requests per second  
  
====== LRANGE_500 (first 450 elements) ======  
  100000 requests completed in 13.50 seconds  
  100 parallel clients  
  3 bytes payload  
  keep alive: 1  
  
0.00% <= 1 milliseconds  
0.01% <= 2 milliseconds  
0.05% <= 3 milliseconds  
2.07% <= 4 milliseconds  
17.32% <= 5 milliseconds  
37.14% <= 6 milliseconds  
54.99% <= 7 milliseconds  
73.80% <= 8 milliseconds  
92.84% <= 9 milliseconds  
99.52% <= 10 milliseconds  
99.94% <= 11 milliseconds  
99.98% <= 12 milliseconds  
99.99% <= 13 milliseconds  
100.00% <= 13 milliseconds  
7409.60 requests per second  
  
====== LRANGE_600 (first 600 elements) ======  
  100000 requests completed in 17.67 seconds  
  100 parallel clients  
  3 bytes payload  
  keep alive: 1  
  
0.00% <= 1 milliseconds  
0.01% <= 2 milliseconds  
0.03% <= 3 milliseconds  
0.04% <= 4 milliseconds  
0.44% <= 5 milliseconds  
5.83% <= 6 milliseconds  
19.29% <= 7 milliseconds  
35.08% <= 8 milliseconds  
52.45% <= 9 milliseconds  
71.43% <= 10 milliseconds  
88.77% <= 11 milliseconds  
98.23% <= 12 milliseconds  
99.73% <= 13 milliseconds  
99.93% <= 14 milliseconds  
99.98% <= 15 milliseconds  
99.98% <= 16 milliseconds  
99.99% <= 17 milliseconds  
100.00% <= 18 milliseconds  
5658.03 requests per second  
  
====== MSET (10 keys) ======  
  100000 requests completed in 1.77 seconds  
  100 parallel clients  
  3 bytes payload  
  keep alive: 1  
  
1.92% <= 1 milliseconds  
61.83% <= 2 milliseconds  
99.23% <= 3 milliseconds  
99.90% <= 5 milliseconds  
99.94% <= 6 milliseconds  
100.00% <= 6 milliseconds  
56433.41 requests per second

 可见,redis服务器的get和set操作每秒处理请求为86000,性能很高,LRANGE操作相比而言性能较低,和要操作的元素数量有关。

 

2.  redis-stat

redis-stat host localhost port 6379 overview

Print general information about a Redis instance; 
实时打印出host为localhost,端口为6379,redis实例的总体信息.

 

redis-stat host localhost port 6379 latency
Measure Redis server latency; 
输出host为localhost,端口为6379,redis服务中每个请求的响应时长.
分享到:
评论

相关推荐

    关于redis状态监控和性能调优详解

    本文主要给大家介绍了关于redis状态监控和性能调优的相关内容,分享出来供大家参考学习,下面话不多说了,来一起看看详细的介绍吧。 1、redis-benchmark redis基准信息,redis服务器性能检测 例如: 检测redis服务器...

    redis-windows-7.0.11

    此外,redis-windows还提供了一些有用的功能,如监控Redis服务器的性能、查看Redis服务器的状态和信息、执行Redis命令等。 总之,redis-windows是一个非常方便的工具,可以帮助Windows用户快速地安装和使用Redis。

    数据存储与管理 + Redis + RedisInsight + 可视化管理

    RedisInsight是一个可视化管理工具,用于管理和...它还提供了自定义仪表板和警报功能,使用户能够更好地了解其Redis实例的状态和性能。RedisInsight也支持多个语言和操作系统,是一款非常实用的Redis可视化管理工具。

    redis非关系型数据库

    一、Redis是什么? 1 是一个高性能的(key/value)分布式内存数据库; 2 是一个NoSql数据库,基于...4 分布式系统下,Redis可以利用哨兵模式Sentinel监控主机工作状态,在Master主服务器发生故障的时候,可以实现Maste

    Redis高级特性解析:持久化、主从复制与哨兵机制全面探讨

    Redis,作为一个高性能的键值对数据库,广泛应用于缓存、消息队列等场景。本文详细探讨了Redis的三大高级特性:持久化、主从复制和哨兵...哨兵通过监控主从节点的健康状态,自动选举新的主节点,确保系统的高可用性。

    Lepus(天兔)是数据库企业监控系统,针对互联网企业开发的一款专业、强大的企业数据库监控管理系统.rar

    Lepus可以在数据库出现故障或者潜在性能问题时,根据用户设置及时将数据库的异常进行报警通知到数据库管理员进行处理和优化,帮助企业解决数据库性能监控问题,及时发现性能和瓶颈,避免由数据库潜在问题造成的直接...

    利用ganglia监控redis的最新解决方法

    Redis现在在业务中应用已经很广泛了,但是如何监控redis,实时的观察redis的性能,在搜索引擎搜索“ganglia监控redis”,发现都是13年的老文章,都是说要到https://github.com/ganglia/gmond_python_modules这个第三...

    基于 Spring Boot 2.1.0 ,Jpa、 Spring Security、redis、Vue前后端分离的后台管理系统

    项目基于 Spring Boot 2.1.0 、 Jpa、 Spring Security、redis、Vue的前后端分离的后台管理系统。...支持在线用户管理与服务器性能监控,支持限制单用户登录。支持运维管理,可方便地对远程服务器的应用进行部署与管理

    caller:自研基于springboot+mybatis+redis+netty 高性能延迟队列

    支持客户端失败重连机制支持服务端访问客户端路由机制支持数据持久化功能支持任务访问失败重连定制化支持访问失败邮件报警功能待增加功能增加页面与用户权限等模块,让使用方更加快捷录入信息增加Redis主从能力增加除...

    Zabbix监控培训视频.rar

    │ 23 05-使用模板监控redis服务.mp4 │ 24 06-监控的维度.mp4 │ 25 07-网站pv_uv_ip的监控.mp4 │ 26 08-使用matomo统计分析web网站.mp4 │ 27 01-使用curl模拟登陆zabbix-web页面.mp4 │ 28 02-zabbix创建web场景...

    lepus:天兔数据库监控系统-官方最新-3.8beta

    国产开源企业级数据库监控系统,MySQL / Oracle / MongoDB / Redis一站式性能监控,让数据库监控更简单 快速开始 您可以使用docker命令行启动映像, mkdir -p /opt/mysql docker run -d --name=lepus -p 80:80 -p ...

    java8看不到源码-captain:基于redis的服务发现

    为了简单和性能,Captain 牺牲了一点高可用性。 大多数情况下,我们没有几万台机器,机器崩溃的可能性非常低,高可用性并不是那么重要。 但是市场上只提供zookeeper/etcd/consul,它们很复杂,至少比captain复杂很多...

    提高redis缓存命中率的方法

    通常来讲,缓存的命中率越高则表示使用缓存的收益越高,应用的性能越好(响应时间越短、吞吐量越高),抗并发的能力越强。 由此可见,在高并发的互联网系统中,缓存的命中率是至关重要的指标。 如何监控缓存的命中率...

    Lepus数据库企业监控系统-其他

    Lepus可以在数据库出现故障或者潜在性能问题时,根据用户设置及时将数据库的异常进行报警通知到数据库管理员进行处理和优化,帮助企业解决数据库性能监控问题,及时发现性能和瓶颈,避免由数据库潜在问题造成的直接...

    UJCMS内容管理系统.rar

    大汉软件推出分布式运营监控平台,通过可视化服务便于用户实时了解分布式环境的运行状态,并根据用户需求个性化定制预警策略,及时掌握运行风险,第一时间对分布式环境进行扩展和性能优化。 预警策略灵活调整 平台...

    eladmin后台管理系统.rar

    EL ADMIN后台管理系统基本简介 EL ADMIN后台管理系统是一个基于 Spring Boot 2.1.0 、 Spring Boot Jpa、 JWT、Spring Security、Redis、Vue的前后端分离的... 支持在线用户管理与服务器性能监控,支持限制单用户登录

    GoMq:基于Redis的Go语言消息植入式系统

    项目地址: : 基于Redis数据库,可以方便进行性能调优,并支持分布式的消息副本,Golang本身又可作为网络服务器,二次开发也非常方便,全部代码才50多行,这大概第一个beta版本,后面考虑添加监控运行状态的功能和...

    决战Nginx系统卷:高性能Web服务器详解与运维第一部分(保证能用)

    第33章 监控Nginx的工作状态 第34章 使用empty_gif 第35章 Nginx对响应体内容的替换 第36章 Nginx的WebDAV 第37章 Nginx的Xslt模块 第38章 Nginx的基本认证方式 第39章 Nginx的cookie 第40章 Nginx基于客户端...

    决战Nginx系统卷:高性能Web服务器详解与运维第二部分(保证能用)

    第33章 监控Nginx的工作状态 第34章 使用empty_gif 第35章 Nginx对响应体内容的替换 第36章 Nginx的WebDAV 第37章 Nginx的Xslt模块 第38章 Nginx的基本认证方式 第39章 Nginx的cookie 第40章 Nginx基于客户端...

Global site tag (gtag.js) - Google Analytics