redis-faina与Redis监控分析

白鳝的洞穴 2020-08-19

2003

Redis是一种单线程的内存数据库系统，其体系较为简单。不过一旦Redis存在一些问题，而我们又没有能力去看源代码的话，还是挺难分析的。老白公司使用Redis的年头也不长，最初的时候拿来开源代码编译一下就开始用了，参数也没做调整，用的过程中难免觉得这玩意也太不稳定了。后来逐渐有了些经验，直到某些地方需要调整优化，才算用的稳定起来。

实际上Redis的监控还是挺简单的，通过info命令可以采集大量的Redis运行状态信息。

clients的信息可以了解当前连接数以及阻塞客户端的数量，从而大体了解客户端的健康状态。

内存小节是最容易误解的，比如used_memory_dataset_perc和used_memory_peak_perc这两个指标是至当前dataset占用Redis内存的比例以及高峰期占用的内存比例，这两个指标永远十分高，接近99%，可能有些朋友就会比较困惑，是不是Redis的内存有问题了。实际上大可不必。你只需要看看maxmemory与used_memory/used_memory_rss的比值就知道Redis的内存情况了，因为Redis总是比较节约的使用内存，只有需要时才去申请新的物理内存，因此只要允许Redis实例使用的内存还有较大剩余，就不怕（如果maxmemory=0，则说明没有限制Redis实例的物理内存使用，此时要看物理内存的空闲情况）。

另外我们要关注CPU的使用情况，这一节数据统计的是自从实例启动以来使用的CPU周期的数量（一个CPU时间片的最高占用时间是1cs，也就是10毫秒），因为Redis是内存数据库，因此占用的核心态cpu周期会比较多。另外Redis是一种单线程数据库，因此Redis只能占用一颗CPU使用，所以不要以为你给Redis配置了一台豪华服务器就OK了，实际上，它根本用不上，判断Redis的CPU资源是否有问题，不能简单的看OS的CPU使用率，而是要看这里的cpu指标，是不是把一颗CPU占用的比较满了，如果比较满了，那你就必须优化你的应用，或者采用分布式，读写分离的方式来进行优化了。

一旦发现Redis出现了性能瓶颈，那怎么来分析呢？一般来说我需要使用monitor工具去分析Redis的命令执行情况，找出其中存在问题的地方。不过monitor看起来十分麻烦，如果导出几万条数据去做分析，只会看的你头昏脑胀。这时候，instgaram开源的redis-faina就可以发挥绝大的作用了。

我们使用monitor命令输出5000行数据，然后用redis-faina去分析。可以看出这个系统的最主要的问题在高可用复制上面。

从这个结果看，处于中位数的命令的响应时间是68毫秒，基本上处于正常水平，75%的命令170+毫秒，性能略差。从这个看，系统的整体性能还可以，不过不是很好。最慢的命令都是来自于高可用复制的。这是一套一主二备读写分离的系统。存在这方面的问题就需要去分析下为什么复制会比较慢了。通过DSMART监控工具我们可以看到这个系统的IO延时情况

这套系统使用的系统盘是比较老的10000RPM SAS盘，IO延时十分不稳定，写盘量稍微大点，IO延时就比较高。这么看，这么看，主从复制存在问题也就很清晰了。

ai redis

文章转载自白鳝的洞穴，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

redis-faina与Redis监控分析

评论