监控redis性能

监控redis性能
http://www.cnblogs.com/mushroom/p/4738170.html


redis-cli -h 192.168.2.59 -p 6000 -a 123456 info | grep -e "connected_clients" -e "blocked_clients" -e "used_memory_human" -e "used_memory_peak_human" -e "rejected_connections" -e "evicted_keys" -e "instantaneous" -e "used_cpu_sys" -e "used_cpu_user"




connected_clients:已连接客户端的数量（不包括通过从属服务器连接的客户端）
blocked_clients:正在等待阻塞命令（BLPOP、BRPOP、BRPOPLPUSH）的客户端的数量
used_memory_human:Redis使用的内存总量
used_memory_peak_human:内存使用的峰值大小
rejected_connections:因为最大客户端连接数限制，而导致被拒绝连接的个数
evicted_keys：因为内存大小限制，而被驱逐出去的键的个数
instantaneous_ops_per_sec：每秒执行的命令个数
instantaneous_input_kbps：每秒读字节数
instantaneous_output_kbps：每秒写字节数
used_cpu_sys:sys cpu使用
used_cpu_user: user cpu使用


The top 5 Redis performance metrics:
1.分配的内存总量used_memory_human




used_memory_human上的数据和used_memory是一样的值，它以M为单位显示，仅为了方便阅读
used_memory是Redis使用的内存总量，它包含了实际缓存占用的内存和Redis自身运行所占用的内存(如元数据、lua)。它是由Redis使用内存分配器分配的内存，所以这个数据并没有把内存碎片浪费掉的内存给统计进去。




监控客户端的连接：因为Redis是单线程模型(只能使用单核)，来处理所有客户端的请求， 但由于客户端连接数的增长，处理请求的线程资源开始降低分配给单个客户端连接的处理时间，这时每个客户端需要花费更多的时间去等待Redis共享服务的响应。这种情况下监控客户端连接数是非常重要的，因为客户端创建连接数的数量可能超出预期的数量，也可能是客户端端没有有效的释放连接。
限制客户端连接数：自Redis2.6以后，允许使用者在配置文件(Redis.conf)maxclients属性上修改客户端连接的最大数，也可以通过在Redis-cli工具上输入config set maxclients 去设置最大连接数。根据连接数负载的情况，这个数字应该设置为预期连接数峰值的110%到150之间，若是连接数超出这个数字后，Redis会拒绝并立刻关闭新来的连接。通过设置最大连接数来限制非预期数量的连接数增长，是非常重要的。






2.total_commands_processed
在info信息里的total_commands_processed字段显示了Redis服务处理命令的总数，其命令都是从一个或多个Redis客户端请求过来的。
分析命令处理总数，诊断响应延迟。


在Redis实例中，跟踪命令处理总数是解决响应延迟问题最关键的部分，因为Redis是个单线程模型，客户端过来的命令是按照顺序执行的。比较常见的延迟是带宽，通过千兆网卡的延迟大约有200μs。倘若明显看到命令的响应时间变慢，延迟高于200μs，那可能是Redis命令队列里等待处理的命令数量比较多。 如上所述，延迟时间增加导致响应时间变慢可能是由于一个或多个慢命令引起的，这时可以看到每秒命令处理数在明显下降，甚至于后面的命令完全被阻塞，导致Redis性能降低。要分析解决这个性能问题，需要跟踪命令处理数的数量和延迟时间。
比如可以写个脚本，定期记录total_commands_processed的值。当客户端明显发现响应时间过慢时，可以通过记录的total_commands_processed历史数据值来判断命理处理总数是上升趋势还是下降趋势，以便排查问题。




使用命令处理总数解决延迟时间增加。


通过与记录的历史数据比较得知，命令处理总数确实是处于上升或下降状态，那么可能是有2个原因引起的:
命令队列里的命令数量过多，后面命令一直在等待中。
几个慢命令阻塞Redis。






redis-cli -h 192.168.2.59 -p 6000 -a 123456 info | grep -e "used_memory_human" -e "total_commands_processed"
3.延迟：
跟踪Redis延迟性能


Redis之所以这么流行的主要原因之一就是低延迟特性带来的高性能，所以说解决延迟问题是提高Redis性能最直接的办法。拿1G带宽来说，若是延迟时间远高于200μs，那明显是出现了性能问题。 虽然在服务器上会有一些慢的IO操作，但Redis是单核接受所有客户端的请求，所有请求是按良好的顺序排队执行。因此若是一个客户端发过来的命令是个慢操作，那么其他所有请求必须等待它完成后才能继续执行。


1. 使用slowlog查出引发延迟的慢命令：Redis中的slowlog命令可以让我们快速定位到那些超出指定执行时间的慢命令，默认情况下命令若是执行时间超过10ms就会被记录到日志。slowlog只会记录其命令执行的时间，不包含io往返操作，也不记录单由网络延迟引起的响应慢。通常1gb带宽的网络延迟，预期在200μs左右，倘若一个命令仅执行时间就超过10ms，那比网络延迟慢了近50倍。 想要查看所有执行时间比较慢的命令，可以通过使用Redis-cli工具，输入slowlog get命令查看，返回结果的第三个字段以微妙位单位显示命令的执行时间。假如只需要查看最后10个慢命令，输入slowlog get 10即可。 关于怎么定位到是由慢命令引起的延迟问题，可查看total_commands_processed介绍章节。
图中字段分别意思是：


1=日志的唯一标识符
2=被记录命令的执行时间点，以 UNIX 时间戳格式表示
3=查询执行时间，以微秒为单位。例子中命令使用54毫秒。
4= 执行的命令，以数组的形式排列。完整命令是config get *。






redis-cli --latency -h 192.168.2.59 -p 6000 -a 123456
redis-cli -h 192.168.2.59 -p 6000 -a 123456
slow get


4.  Fragmentation  Ratio 
used_memory_rss/used_memory
used_memory_rss:系统给redis分配的内存（即常驻内存）


used_memory: redis当前数据使用的内存，有可能包括SWAP虚拟内存。
used_memory_rss: redis当前占用的物理内存，包括内存碎片。此值和用top命令查看的进程占用内存一致。 


mem_fragmentation_ratio：used_memory_rss/used_memory , 此值很重要，当mem_fragmentation_ratio <1 时，说明used_memory > used_memory_rss，这时Redis已经在使用SWAP，运行性能会受很大影响。通常在正常情况下，该值比1大一些。 如何避免mem_fragmentation_ratio <1？我们需要在redis.conf文件中正确配置Redis内存管理的三个参数：maxmemory、maxmemory-policy、maxmemory-samples。




如果内存碎片率超过1.5，那就说明Redis消耗了实际需要物理内存的150%，其中50%是内存碎片率
用内存碎片率预测性能问题


倘若内存碎片率超过了1.5，那可能是操作系统或Redis实例中内存管理变差的表现。下面有3种方法解决内存管理变差的问题，并提高Redis性能：


1. 重启Redis服务器：如果内存碎片率超过1.5，重启Redis服务器可以让额外产生的内存碎片失效并重新作为新内存来使用，使操作系统恢复高效的内存管理。额外碎片的产生是由于Redis释放了内存块，但内存分配器并没有返回内存给操作系统，这个内存分配器是在编译时指定的，可以是libc、jemalloc或者tcmalloc。 通过比较used_memory_peak, used_memory_rss和used_memory_metrics的数据指标值可以检查额外内存碎片的占用。从名字上可以看出，used_memory_peak是过去Redis内存使用的峰值，而不是当前使用内存的值。如果used_memory_peak和used_memory_rss的值大致上相等，而且二者明显超过了used_memory值，这说明额外的内存碎片正在产生。 在Redis-cli工具上输入info 
在重启服务器之前，需要在Redis-cli工具上输入shutdown save命令，意思是强制让Redis数据库执行保存操作并关闭Redis服务，这样做能保证在执行Redis关闭时不丢失任何数据。 在重启后，Redis会从硬盘上加载持久化的文件，以确保数据集持续可用。
2.限制内存交换： 如果内存碎片率低于1，Redis实例可能会把部分数据交换到硬盘上。内存交换会严重影响Redis的性能，所以应该增加可用物理内存或减少实Redis内存占用。 可查看used_memory章节的优化建议。




回收key
info信息中的evicted_keys字段显示的是，因为maxmemory限制导致key被回收删除的数量。
关于maxmemory的介绍见前面章节，回收key的情况只会发生在设置maxmemory值后，不设置会发生内存交换。 当Redis由于内存压力需要回收一个key时，Redis首先考虑的不是回收最旧的数据，而是在最近最少使用的key或即将过期的key中随机选择一个key，从数据集中删除。


这可以在配置文件中设置maxmemory-policy值为“volatile-lru”或“volatile-ttl”，来确定Redis是使用lru策略还是过期时间策略。 倘若所有的key都有明确的过期时间，那过期时间回收策略是比较合适的。若是没有设置key的过期时间或者说没有足够的过期key，那设置lru策略是比较合理的，这可以回收key而不用考虑其过期状态。


根据key回收定位性能问题


跟踪key回收是非常重要的，因为通过回收key，可以保证合理分配Redis有限的内存资源。如果evicted_keys值经常超过0，那应该会看到客户端命令响应延迟时间增加，因为Redis不但要处理客户端过来的命令请求，还要频繁的回收满足条件的key。
需要注意的是，回收key对性能的影响远没有内存交换严重，若是在强制内存交换和设置回收策略做一个选择的话，选择设置回收策略是比较合理的，因为把内存数据交换到硬盘上对性能影响非常大(见前面章节)。


减少回收key以提升性能


减少回收key的数量是提升Redis性能的直接办法，下面有2种方法可以减少回收key的数量：


1.增加内存限制：倘若开启快照功能，maxmemory需要设置成物理内存的45%，这几乎不会有引发内存交换的危险。若是没有开启快照功能，设置系统可用内存的95%是比较合理的，具体参考前面的快照和maxmemory限制章节。如果maxmemory的设置是低于45%或95%(视持久化策略)，通过增加maxmemory的值能让Redis在内存中存储更多的key，这能显著减少回收key的数量。 若是maxmemory已经设置为推荐的阀值后，增加maxmemory限制不但无法提升性能，反而会引发内存交换，导致延迟增加、性能降低。 maxmemory的值可以在Redis-cli工具上输入config set maxmemory命令来设置。
需要注意的是，这个设置是立即生效的，但重启后丢失，需要永久化保存的话，再输入config rewrite命令会把内存中的新配置刷新到配置文件中。


2.对实例进行分片：分片是把数据分割成合适大小，分别存放在不同的Redis实例上，每一个实例都包含整个数据集的一部分。通过分片可以把很多服务器联合起来存储数据，相当于增加总的物理内存，使其在没有内存交换和回收key的策略下也能存储更多的key。假如有一个非常大的数据集，maxmemory已经设置，实际内存使用也已经超过了推荐设置的阀值，那通过数据分片能明显减少key的回收，从而提高Redis的性能。 分片的实现有很多种方法，下面是Redis实现分片的几种常见方式：


a. Hash分片：一个比较简单的方法实现，通过Hash函数计算出key的Hash值，然后值所在范围对应特定的Redis实例。
b. 代理分片：客户端把请求发送到代理上，代理通过分片配置表选择对应的Redis实例。 如Twitter的Twemproxy，豌豆荚的codis。
c. 一致性Hash分片： 参见前面博客《一致性Hash分片详解》
d. 虚拟桶分片：参见前面博客《虚拟桶分详解》




redis-stat 第三方统计分析工具


yum install ruby ruby-devel rubygems gcc-c++ -y
gem install redis-stat
执行监控：
redis-stat --server 192.168.2.59:6000 -a 123456 


Redis Live 第三方统计分析工具
http://www.nkrode.com/article/real-time-dashboard-for-redis


安装：
pip install tornado
pip install redis
pip install python-dateutil
pip install argparse
git clone https://github.com/kumarnitin/RedisLive.git
cd RedisLive/src
cp redis-live.conf.example redis-live.conf


[root@localhost src]# more redis-live.conf
{
        "RedisServers":
        [ 
                {
                        "server": "192.168.2.59",
                        "port" : 6000,
                        "password" : 123456
                },


                {
                        "server": "192.168.2.61",
                        "port" : 6000,
                        "password" : 123456
                }
        ],


        "DataStoreType" : "redis",


        "RedisStatsServer":
        {
                "server" : "192.168.2.61",
                "port" : 6000,
                "password" : 123456
        },


        "SqliteStatsStore" :
        {
                "path":  "/opt/redis/node6000/sqlite.dbf"
        }
}




./redis-monitor.py --duration=120 &
./redis-live.py
http://localhost:8888/index.html




http://192.168.2.61:8888/index.html




压力测试：
redis-benchmark -h 192.168.2.59 -p 6000 -a 123456 -c 900 -n 10000 -q
redis-benchmark -h 192.168.2.59 -p 6000 -a 123456 -c 900 -n 10000 
-c 900:900并发
-n 10000:10000请求（增删改查


100.00% <= 6023 milliseconds
1652.89 requests per second
所有请求在60秒内完成
每秒处理1652.89次请求






redis-benchmark -h 192.168.2.61 -p 6000 -a 123456 -c 900 -n 10000 




4、Redis中CPU使用效率优化


 


将no-appendfsync-on-rewrite的配置设为yes可以缓解这个问题，设置为yes表示rewrite期间对新写操作不fsync，暂时存在内存中，等rewrite完成后再写入。


最好是不开启Master的AOF备份功能。


Redis也可以关闭自动持久化，注释掉这些save配置，或者save “”


如果后台保存到磁盘发生错误,将停止写操作。


stop-writes-on-bgsave-error yes。


使用LZF压缩rdb文件,这会耗CPU, 但是可以减少磁盘占用。


rdbcompression yes


保存rdb和加载rdb文件的时候检验，可以防止错误，但是要付出约10%的性能，可以关闭他，提高性能。


rdbchecksum yes






http://www.penglixun.com/tech/database/mysql_multi_using_numactl.html
http://www.searchtb.com/2012/12/%E7%8E%A9%E8%BD%ACcpu-topology.html
yum install numactl -y






[root@rac3 ~]# numactl --hardware
available: 2 nodes (0-1)
node 0 size: 12091 MB
node 0 free: 69 MB
node 1 size: 12120 MB
node 1 free: 31 MB
node distances:
node   0   1 
  0:  10  20 
  1:  20  10 


直接查看Socket个数:物理CPU个数
cat /proc/cpuinfo|grep "physical id"|sort -u |wc -l
查看core的数量
cat /proc/cpuinfo |grep "cpu cores"|uniq|cut -d: -f2


numactl --show |grep nodebind | cut -d: -f2
  
将redis实例绑定到一个node上
numactl --cpunodebind=0 --localalloc redis-server  redis_master_59.conf
numactl --cpunodebind=0 --membind=0 redis-server  redis_master_59.conf


python操作redis
http://www.tuicool.com/articles/fYrQRz






--------------------------


redis cpu占用过高排查




redis是用"单线程-多路复用io模型"来实现高性能的内存数据服务的，这种机制避免了使用锁，但是同时这种机制在进行sunion之类的比较耗时的命令时会使redis的并发下降。因为是单一线程，所以同一时刻只有一个操作在进行，所以，耗时的命令会导致并发的下降，不只是读并发，写并发也会下降。而单一线程也只能用到一个cpu核心，所以可以在同一个多核的服务器中，可以启动多个实例，组成master-master或者master-slave的形式，耗时的读命令可以完全在slave进行




我这个是redis连接数过多导致
出现cpu过高的原因有：
1、连接数过多，通过redis-cli info | grep connected_clients查看
2、慢查询，因为redis是单线程，如果有慢查询的话，会阻塞住之后的操作，通过redis日志查 
3、value值过大？比如value几十兆，当然这种情况比较少，其实也可以看做是慢查询的一种
4、aof重写/rdb fork发生？瞬间会堵一下Redis服务器


对应解决方案：
1、连接数过多解决：
1.1关闭僵尸连接
采用redi-cli登录,采用client kill ip:port(redis远程连接的ip和端口)。 
需要采用脚本批量删除多个连接
1.2修改redis timeout参数
采用redis-cli登录，采用config set timeout xx 设置redis的keepalive时间
1.3修改redis进程的文件数限制
echo -n "Max open files  3000:3000" >  /proc/PID/limits
1.4修改系统参数的最大文件数限制
/etc/security/limits.conf 
2、对慢查询进行持久化，比如定时存放到mysql之类。（redis的慢查询只是一个list，超过list设置的最大值，会清除掉之前的数据，也就是看不到历史）
3、限制key的长度和value的大小




使用redis的注意事项:
1、Master最好不要做任何持久化工作，包括内存快照和AOF日志文件，特别是不要启用内存快照做持久化。
2、如果数据比较关键，某个Slave开启AOF备份数据，策略为每秒同步一次。
3、为了主从复制的速度和连接的稳定性，Slave和Master最好在同一个局域网内。
4、尽量避免在压力较大的主库上增加从库
5、为了Master的稳定性，主从复制不要用图状结构，用单向链表结构更稳定，即主从关系为：Master<--Slave1<--Slave2<--Slave3.......，这样的结构也方便解决单点故障问题，实现Slave对Master的替换，也即，如果Master挂了，可以立马启用Slave1做Master，其他不变
6、使用Redis负载监控工具：redis-monitor，它是一个Web可视化的 redis 监控程序

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/91975/viewspace-2125706/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/91975/viewspace-2125706/