前言 redis性能分析常见的有以下几个方面: redis slowlog分析 SCAN,SSCAN,HSCAN和ZSCAN命令的使用方法 redis是否受到系统使用swap redis watchdog 定位延时 关于redis的延时监控框架,可参考官网资料下面我们分别从这几个方面来介绍 redis slowlog分析 慢查询设置在Redis中有两种修改配置的方法,一种是修改配置文件 slowlog-log-slower-than 127.0.0.1:6379> sadd setone 1 2 3 foo foobar feelsgood (integer) 6 redis 127.0.0.1:6379> sscan setone 2) "Tom" 3) "age" 4) "35" Linux内核启用了透明巨页功能时,Redis在使用fork调用之后会产生大的延迟代价,以便在磁盘进行数据持久化 echo watchdog定位延时 注意:实验功能,请确保redis数据已备份,会对redis服务性能产生影响 Redis software watchdog #该功能只能动态启用,使用以下命令: CONFIG
在一些网络服务的系统中,Redis 的性能,可能是比 MySQL 等硬盘数据库的性能更重要的课题。 比如微博,把热点微博、最新的用户关系都存储在 Redis 中,大量的查询击中 Redis,而不走 MySQL。 那么,针对 Redis 服务,我们能做哪些性能优化呢? 或者说,应该避免哪些性能浪费呢? Redis 性能的基本面 在讨论优化之前,我们需要知道,Redis 服务本身就有一些特性,比如单线程运行。 除非修改 Redis 的源代码,不然这些特性,就是我们思考性能优化的基本面。 那么,有哪些 Redis 基本特性需要我们考虑呢? 考虑操作系统和硬件是否影响性能 Redis 运行的外部环境,也就是操作系统和硬件显然也会影响 Redis 的性能。
Redis性能分析有几个大的方向。 分别是 (1)基准对比 (2)配置优化 (3)数据持久化 (4)键值优化 (5)缓存淘汰 (6)Redis集群 基准对比 在没有业务实例运行的情况下,在服务器上通过测试Redis 实例的基准性能来对比有实例运行情况下的 redis性能。 -i 1 3.对比实例运行的redis延迟 1Gb/s的网络的延迟差不多是200us,如果指令的响应延迟明显大于200us,可能是请求队列过多导致。 如果实例的延迟时间是Redis基准性能时间的1.5-2倍以上,可以认为这个Redis实例性能比较差 配置优化 linux配置优化 vm.overcommit_memory Redis是内存数据库
来源:rrd.me/gteAC 嘿,我是咸鱼,之前给大家推荐过关于 redis 的不少干货,这次再一起学习一下 Redis 的性能分析。 在一些网络服务的系统中,Redis 的性能,可能是比 MySQL 等硬盘数据库的性能更重要的课题。 关于最后这个特性,为什么 Redis 是单线程的,却能有很好的性能(根据 Amdahl’s Law,优化耗时占比大的过程,才更有意义),两句话概括是:Redis 利用了多路 I/O 复用机制[3],处理客户端请求时 考虑操作系统和硬件是否影响性能 Redis 运行的外部环境,也就是操作系统和硬件显然也会影响 Redis 的性能。 /topics/latency#single-threaded-nature-of-redis [3] 多路 I/O 复用机制: https://redis.io/topics/clients#how-client-connections-are-accepted
什么是AOF AOF是redis防止数据丢失的日志备份策略,总共有三种方式 Always 同步写回:每个写命令执行完同步地将日志写回磁盘;可靠性高,数据基本不会丢失,但同时每次命令都需要写到磁盘,性能影响比较大 ,可能会丢失1s左右的数据,但是性能得到了保证。 另外一点,RDB和AOF对客户端的写入性能影响,一般情况下,AOF的写入性能是比不上RDB的,因为AOF多了一个写入操作,但是随着写入数据量越来越大,这个差距会越来越小。 1、开启AOF 2、没有RDB和AOF进程运行 3、auto-aof-rewrite-min-size:AOF 文件大小绝对值的最小值,默认为 64MB,具体见redis.conf。 看到这里,再想想,为什么redis之所以添加各种条件限制AOF的发生? 尽可能减少CPU和IO消耗 3. 如何避免AOF造成的影响 3.1.
Redis集群性能问题深度分析 参考 Redis开发与运维 https://redis.io/ http://www.redis.cn/ https://github.com/antirez/redis 4,建立了CacheCloud监控系统,便于分析观察问题,另外Zabbix也使用Redis模版出现大故障时会报错。 6,每个Redis集群版本升级在功能与性能上都有比较大的提升,需要持久化功能的集群后续可以使用4.0.2版本,另外如果使用虚拟化不建议使用XEN、Hyper-V等,最好使用vSphere压力测试vSphere 3,网络问题 1)连接拒绝 主要是网络闪断接Redis连接数超过默认的10000,可以通过监控与修改默认值规避。 2)网络延迟 3)网卡软中断
完工后对服务进行压测后发现georadius的性能比预期要差,因此我分析了georadius的源码,并对原始的实现方案进行了优化,总结成了本文。 我们生产环境使用的redis版本为4.0.13,因此本文redis源码皆为4.0.13版本的源码 redis geo原理 往redis中添加坐标的命令是GEOADD key longitude latitude 又因为redis工作线程是单线程的,因此无法充分利用多核,无法通过增加redis server的CPU核数来提升性能,只能添加从库。 17 5.8 16 66 Waiting: 3 16 5.8 16 66 Total: 3 17 5.8 80% 22 90% 24 95% 26 98% 28 99% 30 100% 66 (longest request) 可以看到当优化后性能更差了
关于Redis的入门 3:浅谈Redis的特点——高性能在谈论Redis时,最常被提及的特点之一就是它的高性能。 作为一个内存数据库,Redis能处理每秒数十万次的操作,其卓越的性能让它成为很多高并发应用的首选存储解决方案。那么,Redis究竟是如何实现如此高效的呢? 本文将详细讲解Redis的高性能特点,并从多个角度深入分析它是如何做到这一点的。1. 为什么Redis的性能如此高?1.1 内存存储Redis的高性能首先得益于它的内存存储特性。 1.5 支持多种缓存策略Redis作为一个缓存系统,其高性能还得益于对多种缓存策略的支持。 消息推送:借助Redis的发布/订阅(Pub/Sub)功能,系统能够实现高效的消息推送,支持低延迟的消息传递。3. 总结Redis的高性能源自其内存存储、单线程模型、简单数据结构以及优化的持久化机制。
其主要作用是将原始跟踪文件格文本文件的类型,例如,最简单的方法,使用下面的: tkprof ly_ora_128636.trc ly_ora_128636.txt tkprof带有非常多參数,在多数情况下,使用这些參数对你的分析将非常有帮助 503 0.03 0.15 0 1465 0 50001 上面分别相应了parse、execute和fetch这3个阶段 不精确 这里你能够看到运行中遇到的等待事件,通过对这些等待事件的分析。有助于你了解在等待什么样的资源,查询的瓶颈,有针对的做出优化。
2、分析redis故障的根本原因 任何一个故障和性能问题,其根本“诱因”往往只有一个,称为这个故障的Root cause。 3、Redis容量规划和性能管理 通过分析redis资源使用和性能指标的监控历史趋势数据;对集群进行合理扩容(Scale-out)、缩容(Scale-back);对性能瓶颈优化处理等。 3、redis性能指标 4、应用的响应时间:Redis慢查询监控 2.1、服务器系统监控 1)、服务器存活监控: 2)CPU 平均负载 (Load Average): 综合负载指标(暂且归类cpu子系统 丢包率 :Redis服务响应质量受影响 2.2、Redis应用进程监控 1)、端口存活 2)、进程占用的cpu和内存 3)、网络连接数 2.3、redis性能指标 可以通过info 命令获取相关性能指标 要分析解决这个性能问题,需要跟踪命令处理数的数量和延迟时间。
前面的话 测试将54w多条数据bak出来,在一台新的redis数据库重载,查看带来的压力 546167) "nssum005471" 546168) "nssum397176" 546169) "nssum196383 " 546170) "nssum163750" (17.14s) redis的aof文件大小 47M root@233:~/redis-5.0.4# ll -h /var/lib/redis/ total 6379> bgsave Background saving started 127.0.0.1:6379> 测试 在重载的某一刻,cpu的idl值直接为0,真是重重的的一击 loading的过程中,redis
背景 初学者对性能分析是个《横看成岭侧成峰,远近高低各不同。不识庐山真面目,只缘身在此山中。》那么应该怎么学习才能建立起自己的知识体系,才能做到《千山同一月,万户尽皆春。 千江有水千江月,万里无云万里天》今天咱们谈谈7DGroup创始人高楼老师的性能分析之决策树分析法。 分析决策树图一 ? 分析决策树图二 ? 这种合并消除了第二个请求的寻道时间,从而提高了总体磁盘性能。当请求被放入磁盘队列时,如果磁盘当前不忙,它将开始为I/O请求提供服务。 作为一名未来的全栈工程师,还是有必要了解每一层做什么,这样在解决性能问题能如鱼得水,如果想深入学习可以参加高老师课程,老师可以把大家讲明白。
} finally { if (rLock.isLocked() && rLock.isHeldByCurrentThread()) { //3. cancelExpirationRenewal(null); } }); } }, internalLockLeaseTime / 3, TimeUnit.MILLISECONDS); ee.setTimeout(task); } 这里还有一个小的点,就是续期的时间是 1/3 为什么呢? 保证在下次续期的时候锁不过期,如果是 1/2 可能在下次定时任务执行的时候 key 已经过期,如果小于 1/3 会导致频繁续期,任务代价/收益比不高。 "end; " + "local counter = redis.call('hincrby', KEYS[1], ARGV[3], -1); " +
\redis-benchmark.exe -n 100 测试结果: ====== PING_INLINE ====== 100 requests completed in 0.00 seconds 50 parallel clients 3 bytes payload keep alive: 1 64.00% <= 1 milliseconds 100.00% <= 1 milliseconds per second ====== PING_BULK ====== 100 requests completed in 0.00 seconds 50 parallel clients 3 requests per second ====== SET ====== 100 requests completed in 0.00 seconds 50 parallel clients 3 100.00% <= 3 milliseconds 16666.67 requests per second ====== LRANGE_500 (first 450 elements) ====
Redis 性能测试 Redis 性能测试是通过同时执行多个命令实现的。 语法 redis 性能测试的基本命令如下: redis-benchmark [option] [option value] 注意:该命令是在redis的目录下执行的,而不是redis客户端的内部指令。 实例 以下实例同时执行10000个请求来检测性能: [root@localhost ~]# redis-benchmark -n 10000 -q PING_INLINE: 99009.90 requests 性能测试工具可选参数如下所示: 序号 选项 描述 默认值 1 -h 指定服务器主机名 127.0.0.1 2 -p 指定服务器端口 6379 3 -s 指定服务器socket 4 -c 指定并发连接数 实例 以下实例我们使用了多个参数来测试redis性能: [root@localhost ~]# redis-benchmark -h 127.0.0.1 -p 6379 -t set,lpush -n
*注意* 每次读写时候,由于电脑性能对比有差异性,所以可以先行通过3.2.4的快速测试,对比一下自己的电脑性能之后再进行测试,因为楼主昨天做测试的时候电脑有些卡,导致今天的数据重新测试时候都快了很多 窗口. 3.1.2 测试过程: 主从均关闭,开启主redis导入少量数据到主redis,开启从redis,从redis有一样的数据. 主从均关闭,开启从redis,删除少量数据到从redis(management tool for redis),开启主redis,主redis数据不变化,刷新从,从redis恢复原来的数据. 主从均开启,操作部分数据到主redis,从redis有同样的数据, 主从均开启,删除部分数据(management tool for redis)到从redis,主redis原有数据不会变动,再次刷新从 通过结果对比分析可以看到,快速的读写操作的速度还是比较高效的,从这里也可以看到电脑性能对于程序的影响,这个是正常编辑代码时候输出的效率,读者可以对比自己的电脑输出的时间,和楼主的数据做一个误差对比
Redis 性能优化 一、Linux 操作系统 ---- 【1】ulimit 与 TCP backlog:1)、修改 ulimit:通过 ulimit 修改 open files 参数,redis 建议把 2)、优化:调整 maxclients,或者优化 redis 命令处理性能。 三、Redis 性能测试 ---- Redis 官网自动 Redis 性能测试工具 Redis-benchmark,可以有效的测试 Redis 服务的性能。 ? 服务器性能 1 . /redis-benchmark -h 127.0.0.1 -p 6379 -c 100 -n 100000 2 3 #对集合写入测试 结果如下 4 100000 requests completed
Redis官方已经说了,Redis有官方自己的性能测试工具! https://redis.io/topics/benchmarks 我们自己试试吧 redis-benchmark [-h <host>] [-p <port>] [-c <clients>] [-n 官方的一个所有种类测试的典型例子 # 测试阶段 服务器CPU性能会占用变高 redis-benchmark -q -n 100000 图片说了 每秒SET 命令能处理34545.32个请求。 其他的自行查看 云服务器CPU更强,性能更好,CPU到95% 跑个5W qps 每问题! 宝塔Redis 的性能测试在:/www/server/redis/src/ # 进入宝塔 redis-benchmark cd /www/server/redis/src # 进行测试 .
一.介绍 redis-benchmark是Redis自带的基准性能测试工具, 它提供了很多选项帮助开 发和运维人员测试Redis的相关性能。 二.例子 50个客户端同时请求Redis,一共一万次。 redis-benchmark -c 50 -n 10000 ====== MSET (10 keys) ====== 10000 requests completed in 0.13 seconds #总共1万次,0.13秒完成 50 parallel clients #50并发 3 bytes payload #每个请求3字节 keep alive: 1 97.81% <= 1 milliseconds milliseconds 100.00% <= 2 milliseconds 77519.38 requests per second #每秒可以处理77519.38次get请求 三.参数 -q 仅仅显示redis-benchmark -P 代表每个请求pipeline的数据量(默认为1) -k 代表客户端是否使用keepalive, 1为使用, 0为不使用, 默认值为1 -t 可以对指定命令进行基准测试 例如:redis-benchmark
要分析解决这个性能问题,需要跟踪命令处理数的数量和延迟时间。 比如可以写个脚本,定期记录total_commands_processed的值。 使用延迟命令提高性能 一旦确定延迟时间是个性能问题后,这里有几个办法可以用来分析解决性能问题。 1. 性能数据指标:分析解决Redis性能问题,通常需要把延迟时间的数据变化与其他性能指标的变化相关联起来。 对于这种性能指标相关联的分析,需要从历史数据上来观察到数据指标的重要变化,此外还可以观察到单个性能指标相关联的所有其他性能指标信息。 下面有3种方法解决内存管理变差的问题,并提高Redis性能: 1.