- 综合排序
- 最热优先
- 最新优先
- 来自专栏运维录
Redis性能分析
前言 redis性能分析常见的有以下几个方面： redis slowlog分析 SCAN，SSCAN，HSCAN和ZSCAN命令的使用方法 redis是否受到系统使用swap redis watchdog 定位延时 关于redis的延时监控框架,可参考官网资料下面我们分别从这几个方面来介绍 redis slowlog分析 慢查询设置在Redis中有两种修改配置的方法,一种是修改配置文件 slowlog-log-slower-than 2) "Tom" 3) "age" 4) "35" Linux内核启用了透明巨页功能时，Redis在使用fork调用之后会产生大的延迟代价，以便在磁盘进行数据持久化 echo swap分区的统计信息，以不使用或只有少量的4kB为佳： cat smaps | grep 'Swap:' #同时打印出内存映射和swap使用信息：查看那些较大的内存消耗是否引发了大的swap使用 cat smaps | egrep '^(Swap:Size)' redis watchdog定位延时 注意：实验功能，请确保redis数据已备份,会对redis服务性能产生影响 Redis
1.6K30发布于 2019-11-19 - 来自专栏对线JAVA面试
Redis 性能问题分析
在一些网络服务的系统中，Redis 的性能，可能是比 MySQL 等硬盘数据库的性能更重要的课题。 比如微博，把热点微博、最新的用户关系都存储在 Redis 中，大量的查询击中 Redis，而不走 MySQL。 那么，针对 Redis 服务，我们能做哪些性能优化呢？ 或者说，应该避免哪些性能浪费呢？ Redis 性能的基本面 在讨论优化之前，我们需要知道，Redis 服务本身就有一些特性，比如单线程运行。 除非修改 Redis 的源代码，不然这些特性，就是我们思考性能优化的基本面。 那么，有哪些 Redis 基本特性需要我们考虑呢？ 考虑操作系统和硬件是否影响性能 Redis 运行的外部环境，也就是操作系统和硬件显然也会影响 Redis 的性能。
89410编辑于 2022-10-27 - 来自专栏公众号-测试驿栈
Redis性能分析思路
Redis性能分析有几个大的方向。 分别是 （1）基准对比 （2）配置优化 （3）数据持久化 （4）键值优化 （5）缓存淘汰 （6）Redis集群 基准对比 在没有业务实例运行的情况下，在服务器上通过测试Redis 实例的基准性能来对比有实例运行情况下的 redis性能。 如果实例的延迟时间是Redis基准性能时间的1.5-2倍以上，可以认为这个Redis实例性能比较差 配置优化 linux配置优化 vm.overcommit_memory Redis是内存数据库 开启时可以降低 fork 子进程的速度，但 fork 操作之后，每个内存页从原来 4KB 变为 2MB，会大幅增加内存消耗，同时拖慢写操作时间，产生大量写操作慢查询。
68820编辑于 2022-05-10 - 来自专栏咸鱼学Python
硬货 | Redis 性能问题分析
来源：rrd.me/gteAC 嘿，我是咸鱼，之前给大家推荐过关于 redis 的不少干货，这次再一起学习一下 Redis 的性能分析。 在一些网络服务的系统中，Redis 的性能，可能是比 MySQL 等硬盘数据库的性能更重要的课题。 ，不会阻塞主线程；Redis 单纯执行（大多数指令）一个指令不到 1 微秒[4]，如此，单核 CPU 一秒就能处理 1 百万个指令（大概对应着几十万个请求吧），用不着实现多线程（网络才是瓶颈[5]）。 个 fields，每个 field 和 value 都是一个 15 位左右的字符串，结果是 hashtable 结构使用的空间是 ziplist 的 4 倍。）。 [4] 1 微秒: https://redis.io/topics/latency#redis-latency-problems-troubleshooting [5] 网络才是瓶颈: https:/
1.2K00发布于 2020-03-16 - 来自专栏让技术和时代并行
redis AOF性能瓶颈分析
什么是AOF AOF是redis防止数据丢失的日志备份策略，总共有三种方式 Always 同步写回：每个写命令执行完同步地将日志写回磁盘；可靠性高，数据基本不会丢失，但同时每次命令都需要写到磁盘，性能影响比较大 ，可能会丢失1s左右的数据，但是性能得到了保证。 由操作系统控制何时写会，性能非常好；如果发生宕机，也会造成大量数据丢失。 说到AOF，其实很多人都会拿它跟Rdb去做比较，Rdb是以二进制的方式存储到磁盘上。 另外一点，RDB和AOF对客户端的写入性能影响，一般情况下，AOF的写入性能是比不上RDB的，因为AOF多了一个写入操作，但是随着写入数据量越来越大，这个差距会越来越小。 具体可以参考redis官网https://redis.io/topics/persistence，这里不过多赘述。 2.
1.4K20编辑于 2023-03-18 - 来自专栏运维
Redis集群性能问题深度分析
Redis集群性能问题深度分析 参考 Redis开发与运维 https://redis.io/ http://www.redis.cn/ https://github.com/antirez/redis 2，集群扩容，升级到3.2.9版本后为了均摊QPS扩容了几个节点，后续发现有2个节点内核版本比其他的高但是性能反而表现比其他差，后替换了同版本的内核。 4，建立了CacheCloud监控系统，便于分析观察问题，另外Zabbix也使用Redis模版出现大故障时会报错。 6，每个Redis集群版本升级在功能与性能上都有比较大的提升，需要持久化功能的集群后续可以使用4.0.2版本，另外如果使用虚拟化不建议使用XEN、Hyper-V等，最好使用vSphere压力测试vSphere 一，发现问题 1，慢查询 slowlog get n 默认保留128个日志执行超过10毫秒的记录，可以根据实际情况修改 2，应用报错 主要是应用邮件报超时 二，分析问题 1，内在原因 1）API或数据结构使用不合理
2.1K11发布于 2018-11-14 - 来自专栏我的独立博客
redis georadius源码分析与性能优化
完工后对服务进行压测后发现georadius的性能比预期要差，因此我分析了georadius的源码，并对原始的实现方案进行了优化，总结成了本文。 我们生产环境使用的redis版本为4.0.13，因此本文redis源码皆为4.0.13版本的源码 redis geo原理 往redis中添加坐标的命令是GEOADD key longitude latitude 1 [-180, 0) [0, 180] [0, 180] 1 2 [0, 90) [90, 180] [90, 180] 1 3 [90, 135) [135, 180] [90, 135]) 0 4 又因为redis工作线程是单线程的，因此无法充分利用多核，无法通过增加redis server的CPU核数来提升性能，只能添加从库。 80% 22 90% 24 95% 26 98% 28 99% 30 100% 66 (longest request) 可以看到当优化后性能更差了
50710编辑于 2024-09-02 - 来自专栏7DGroup
性能分析之分析决策树3与4
背景 初学者对性能分析是个《横看成岭侧成峰，远近高低各不同。不识庐山真面目，只缘身在此山中。》那么应该怎么学习才能建立起自己的知识体系，才能做到《千山同一月,万户尽皆春。 千江有水千江月,万里无云万里天》今天咱们谈谈7DGroup创始人高楼老师的性能分析之决策树分析法。 分析决策树图一 ? 分析决策树图二 ? 这种合并消除了第二个请求的寻道时间，从而提高了总体磁盘性能。当请求被放入磁盘队列时，如果磁盘当前不忙，它将开始为I/O请求提供服务。 作为一名未来的全栈工程师，还是有必要了解每一层做什么，这样在解决性能问题能如鱼得水，如果想深入学习可以参加高老师课程，老师可以把大家讲明白。
82620发布于 2019-12-11 - 来自专栏架构师成长之路
Redis详解（6）性能监控：问题分析和优化
2、分析redis故障的根本原因 任何一个故障和性能问题，其根本“诱因”往往只有一个，称为这个故障的Root cause。 3、Redis容量规划和性能管理 通过分析redis资源使用和性能指标的监控历史趋势数据；对集群进行合理扩容(Scale-out)、缩容(Scale-back)；对性能瓶颈优化处理等。 Redis性能监控管理，及时发现性能瓶颈，进行优化或扩容，把问题扼杀在”萌芽期“，避免它”进化“成故障。 4、Redis硬件资源利用率和成本 从老板角度来看，最关心的是成本和资源利用率是否达标。 3、redis性能指标 4、应用的响应时间：Redis慢查询监控 2.1、服务器系统监控 1)、服务器存活监控： 2）CPU 平均负载 (Load Average): 综合负载指标(暂且归类cpu子系统 要分析解决这个性能问题，需要跟踪命令处理数的数量和延迟时间。
4.1K21编辑于 2022-04-14 - 来自专栏用户8851537的专栏
Redis之AOF持久化文件重载性能分析
前面的话 测试将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
37130发布于 2021-07-27 - 来自专栏自动化、性能测试
性能分析（4）- iowait 使用率过高案例
性能分析小案例系列，可以通过下面链接查看哦 https://www.cnblogs.com/poloyy/category/1814570.html 前言 前面两个案例讲的都是上下文切换导致的 CPU 结果分析 平均负载，过去 1min、5min、15min 的平均负载依次减少，说明平均负载正在升高 而 1min 内的平均负载已经达到系统 CPU 个数，说明系统很可能存在性能瓶颈 115 zombie 这进程已经是 Z 状态，就是僵尸进程了 僵尸进程都是已经退出的进程， 所以就没法儿继续分析它的系统调用 关于僵尸进程的处理方法，我们一会儿再说，现在还是继续分析 iowait 的问题 通过 perf 录制性能事件 查看报告，分析报告 perf report ? I/O 类型的进程在运行时，iowait 也会很高，但实际上，磁盘的读写远没有达到性能瓶颈的程度 分析整体思路 通过 top 查看系统资源情况 发现平均负载逐渐升高，iowait（wa）比较高，但用户态和内核态
5K42发布于 2020-08-12 - 来自专栏运维开发故事
Redisson 高性能 Redis 分布式锁源码分析
当线程 1 释放锁之后，会触发 redis 的解锁消息，消息的观察者会观察到然后去唤醒解锁的逻辑，线程 2 继续竞争锁。 配置部分 Config config = new Config(); String address = "redis://127.0.0.1:6379"; ('exists', KEYS[1]) == 0) then " + "redis.call('hincrby', KEYS[1], ARGV[2], 1 ); " + "redis.call('pexpire', KEYS[1], ARGV[1]); " + "return nil; " + "end; " + "if (redis.call('hexists',
1.2K30编辑于 2022-09-15 - 来自专栏极客运维
【redis从入门到上线(4)】- redis高可用架构横向对比分析
redis架构分析 上篇我们讲解完 Redis Sentinel 原理之后，接下来讲解常用的 Redis 高可用架构。 优点： 服务探测故障及时 DBA 维护成本低 缺点： 依赖客户端支持 Sentinel Sentinel 服务器和 Redis 节点需要开放访问权限 对应用有侵入性 4.Redis Sentinel 集群 Redis 3.0.0 在 2015 年 4 月 2 日正式发布，距今已有两年多的时间。Redis 集群采用 P2P 模式，无中心化。 优点： 开发简单，对应用几乎透明 历史悠久，方案成熟 缺点： 代理影响性能 LVS 和 Twemproxy 会有节点性能瓶颈 Redis 扩容非常麻烦 Twitter 内部已放弃使用该方案且不再在GitHub 优点： 开发简单，对应用几乎透明 性能在特定情况下比Twemproxy好 有图形化界面，扩容容易，运维方便 缺点： 代理依旧影响性能 组件过多，需要很多机器资源 修改了 Redis 代码，导致和官方无法同步
87720发布于 2019-12-26 - 来自专栏温安适的blog
4R分析redis处理客户端请求
当sokect有新的可读数据时，触发事件，保证 Redis 能够立即收集客户端查询检查是否达到最大客户端数量限制（ maxclients），若已达到最大客户端数，redis会尝试向客户端发送错误信息并立即关闭连接 maxclients说明Redis 2.6 +， redis.conf 中可以配置maxclients，默认10000，最大客户端数 = min（ maxclients+32，能够打开的文件描述符的最大数量 ）32是redis预留的clients数量。 当达到限制时，客户端连接关闭，事件记录在 Redis 日志文件中。Redis 使用了两种限制：硬限制是一个固定限制，当达到该限制时，Redis 会尽快关闭客户端连接。 redis.conf中配置，或者CONFIG SET timeout 。
1K40编辑于 2022-07-19 - 来自专栏后端码事
Redis 性能测试
\redis-benchmark.exe -n 100 测试结果： ====== PING_INLINE ====== 100 requests completed in 0.00 seconds keep alive: 1 1.00% <= 1 milliseconds 28.00% <= 2 milliseconds 66.00% <= 3 milliseconds 86.00% <= 4 keep alive: 1 1.00% <= 1 milliseconds 12.00% <= 2 milliseconds 43.00% <= 3 milliseconds 67.00% <= 4
84150发布于 2020-09-11 - 来自专栏用户8644135的专栏
Redis 性能测试
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
1.1K20发布于 2021-07-02 - 来自专栏*坤的Blog
redis性能测试
*注意* 每次读写时候,由于电脑性能对比有差异性,所以可以先行通过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原有数据不会变动,再次刷新从 通过结果对比分析可以看到,快速的读写操作的速度还是比较高效的,从这里也可以看到电脑性能对于程序的影响,这个是正常编辑代码时候输出的效率,读者可以对比自己的电脑输出的时间,和楼主的数据做一个误差对比
3.3K21发布于 2018-06-04 - 来自专栏Java实战博客
Redis 性能测试
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 # 进行测试 .
85820编辑于 2022-01-19 - 来自专栏Java架构师必看
Redis 性能优化
Redis 性能优化 一、Linux 操作系统 ---- 【1】ulimit 与 TCP backlog：1）、修改 ulimit：通过 ulimit 修改 open files 参数，redis 建议把 echo "vm.swappiness=1" > /etc/sysctl.conf 【4】Transparent Huge Pages：支持大内存分页（2MB）分配，默认开启，redis 建议关闭此功能 2）、优化：调整 maxclients，或者优化 redis 命令处理性能。 三、Redis 性能测试 ---- Redis 官网自动 Redis 性能测试工具 Redis-benchmark，可以有效的测试 Redis 服务的性能。 ? /redis-benchmark -h 127.0.0.1 -p 6379 -c 100 -n 100000 2 3 #对集合写入测试 结果如下 4 100000 requests completed
2.1K30发布于 2021-04-25 - 来自专栏兜兜毛毛
Redis Set (4)
存储（实现）原理 Redis用intset或hashtable存储set。如果元素都是整数类型，就用inset存储。如果不是整数类型，就用hashtable（数组+链表的存来储结构）。 redis.conf set-max-intset-entries 512 127.0.0.1:6379> sadd lset 1 2 3 3 4 5 6 7 (integer) 7 127.0.0.1
36920发布于 2020-03-19
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号