性能相干的数据指标

通过Redis-cli命令行界面拜访到Redis服务器，而后应用info命令获取所有与Redis服务相干的信息。通过这些信息来剖析文章前面提到的一些性能指标。

info命令输入的数据可分为10个类别，别离是：

  • server
  • clients
  • memory
  • persistence
  • stats
  • replication
  • cpu
  • commandstats
  • cluster
  • keyspace

这篇次要介绍比拟重要的2局部性能指标memory和stats。

须要留神的是info命令返回的信息，并没有命令响应提早相干的数据信息，所以前面会具体介绍怎么获取与提早相干的数据指标。

假使你感觉info输入的信息太多并且横七竖八，能够指定info命令的参数来获取单个分类下的数据。比方输出info memory命令，会只返回与内存相干的数据。

为了疾速定位并解决性能问题，这里抉择5个关键性的数据指标，它蕴含了大多数人在应用Redis上会常常碰到的性能问题。

内存使用率used_memory

上图中used_memory 字段数据表示的是：由Redis分配器调配的内存总量，以字节（byte）为单位。 其中used_memory_human上的数据和used_memory是一样的值，它以M为单位显示，仅为了不便浏览。

used_memory是Redis应用的内存总量，它蕴含了理论缓存占用的内存和Redis本身运行所占用的内存(如元数据、lua)。它是由Redis应用内存分配器调配的内存，所以这个数据并没有把内存碎片节约掉的内存给统计进去。

其余字段代表的含意，都以字节为单位：

  • used_memory_rss：从操作系统上显示曾经调配的内存总量。
  • mem_fragmentation_ratio： 内存碎片率。
  • used_memory_lua： Lua脚本引擎所应用的内存大小。
  • mem_allocator： 在编译时指定的Redis应用的内存分配器，能够是libc、jemalloc、tcmalloc。

因内存替换引起的性能问题

内存使用率是Redis服务最要害的一部分。如果一个Redis实例的内存使用率超过可用最大内存 (used_memory > 可用最大内存)，那么操作系统开始进行内存与swap空间替换，把内存中旧的或不再应用的内容写入硬盘上（硬盘上的这块空间叫Swap分区），以便腾出新的物理内存给新页或流动页(page)应用。

在硬盘上进行读写操作要比在内存上进行读写操作，工夫上慢了近5个数量级，内存是0.1s单位、而硬盘是10ms。如果Redis过程上产生内存替换，那么Redis和依赖Redis上数据的利用会受到重大的性能影响。

通过查看used_memory指标可晓得Redis正在应用的内存状况，如果used_memory>可用最大内存，那就阐明Redis实例正在进行内存替换或者曾经内存替换结束。管理员依据这个状况，执行绝对应的应急措施。

跟踪内存使用率

若是在应用Redis期间没有开启rdb快照或aof长久化策略，那么缓存数据在Redis解体时就有失落的危险。因为当Redis内存使用率超过可用内存的95%时，局部数据开始在内存与swap空间来回替换，这时就可能有失落数据的危险。

当开启并触发快照性能时，Redis会fork一个子过程把以后内存中的数据齐全复制一份写入到硬盘上。因而若是以后应用内存超过可用内存的45%时触发快照性能，那么此时进行的内存替换会变的十分危险(可能会失落数据)。 假使在这个时候实例上有大量频繁的更新操作，问题会变得更加重大。

通过缩小Redis的内存占用率，来防止这样的问题，或者应用上面的技巧来防止内存替换产生：

1）如果缓存数据小于4GB，就应用32位的Redis实例。因为32位实例上的指针大小只有64位的一半，它的内存空间占用空间会更少些。 这有一个害处就是，假如物理内存超过4GB，那么32位实例能应用的内存依然会被限度在4GB以下。 要是实例同时也共享给其余一些利用应用的话，那可能须要更高效的64位Redis实例，这种状况下切换到32位是不可取的。 不论应用哪种形式，Redis的dump文件在32位和64位之间是相互兼容的， 因而假使有缩小占用内存空间的需要，能够尝试先应用32位，前面再切换到64位上。

2）尽可能的应用Hash数据结构。因为Redis在贮存小于100个字段的Hash构造上，其存储效率是十分高的。所以在不须要汇合(set)操作或list的push/pop操作的时候，尽可能的应用Hash构造。比方，在一个web应用程序中，须要存储一个对象示意用户信息，应用单个key示意一个用户，其每个属性存储在Hash的字段里，这样要比给每个属性独自设置一个key-value要高效的多。 通常状况下假使有数据应用string构造，用多个key存储时，那么应该转换成单key多字段的Hash构造。 如上述例子中介绍的Hash构造应蕴含，单个对象的属性或者单个用户各种各样的材料。Hash构造的操作命令是HSET(key, fields, value)和HGET(key, field)，应用它能够存储或从Hash中取出指定的字段。

3）设置key的过期工夫。一个缩小内存使用率的简略办法就是，每当存储对象时确保设置key的过期工夫。假使key在明确的工夫周期内应用或者旧key不大可能被应用时，就能够用Redis过期工夫命令(expire,expireat, pexpire, pexpireat)去设置过期工夫，这样Redis会在key过期时主动删除key。 如果你晓得每秒钟有多少个新key-value被创立，那能够调整key的存活工夫，并指定阀值去限度Redis应用的最大内存。

4）回收key。在Redis配置文件中(个别叫Redis.conf)，通过设置“maxmemory”属性的值能够限度Redis最大应用的内存，批改后重启实例失效。 也能够应用客户端命令config set maxmemory 去批改值，这个命令是立刻失效的，但会在重启后会生效，须要应用config rewrite命令去刷新配置文件。 若是启用了Redis快照性能，应该设置“maxmemory”值为零碎可应用内存的45%，因为快照时须要一倍的内存来复制整个数据集，也就是说如果以后已应用45%，在快照期间会变成95%(45%+45%+5%)，其中5%是预留给其余的开销。 如果没开启快照性能，maxmemory最高能设置为零碎可用内存的95%。

当内存应用达到设置的最大阀值时，须要抉择一种key的回收策略，可在Redis.conf配置文件中批改“maxmemory-policy”属性值。 若是Redis数据集中的key都设置了过期工夫，那么“volatile-ttl”策略是比拟好的抉择。但如果key在达到最大内存限度时没可能迅速过期，或者基本没有设置过期工夫。那么设置为“allkeys-lru”值比拟适合，它容许Redis从整个数据集中筛选最近起码应用的key进行删除(LRU淘汰算法)。Redis还提供了一些其余淘汰策略，如下：

  • volatile-lru：应用LRU算法从已设置过期工夫的数据汇合中淘汰数据。
  • volatile-ttl：从已设置过期工夫的数据汇合中筛选行将过期的数据淘汰。
  • volatile-random：从已设置过期工夫的数据汇合中随机筛选数据淘汰。
  • allkeys-lru：应用LRU算法从所有数据汇合中淘汰数据。
  • allkeys-random：从数据汇合中任意抉择数据淘汰
  • no-enviction：禁止淘汰数据。

通过设置maxmemory为零碎可用内存的45%或95%(取决于长久化策略)和设置“maxmemory-policy”为“volatile-ttl”或“allkeys-lru”(取决于过期设置)，能够比拟精确的限度Redis最大内存使用率，在绝大多数场景下应用这2种形式可确保Redis不会进行内存替换。假使你放心因为限度了内存使用率导致失落数据的话，能够设置noneviction值禁止淘汰数据。

命令解决数total_commands_processed

在info信息里的total_commands_processed字段显示了Redis服务解决命令的总数，其命令都是从一个或多个Redis客户端申请过去的。Redis每时每刻都在解决从客户端申请过去的命令，它能够是Redis提供的140种命令的任意一个。 total_commands_processed字段的值是递增的，比方Redis服务别离解决了client_x申请过去的2个命令和client_y申请过去的3个命令，那么命令解决总数(total_commands_processed)就会加上5。

剖析命令解决总数，诊断响应提早。

在Redis实例中，跟踪命令解决总数是解决响应提早问题最要害的局部，因为Redis是个单线程模型，客户端过去的命令是依照程序执行的。比拟常见的提早是带宽，通过千兆网卡的提早大概有200s。假使显著看到命令的响应工夫变慢，提早高于200s，那可能是Redis命令队列里期待解决的命令数量比拟多。

如上所述，延迟时间减少导致响应工夫变慢可能是因为一个或多个慢命令引起的，这时能够看到每秒命令解决数在显著降落，甚至于前面的命令齐全被阻塞，导致Redis性能升高。要剖析解决这个性能问题，须要跟踪命令解决数的数量和延迟时间。

比方能够写个脚本，定期记录total_commands_processed的值。当客户端显著发现响应工夫过慢时，能够通过记录的total_commands_processed历史数据值来判断命理解决总数是回升趋势还是降落趋势，以便排查问题。

应用命令解决总数解决延迟时间减少。

通过与记录的历史数据比拟得悉，命令解决总数的确是处于回升或降落状态，那么可能是有2个起因引起的:

  • 命令队列里的命令数量过多，前面命令始终在期待中。
  • 几个慢命令阻塞Redis。

上面有三个方法能够解决，因下面2条起因引起的响应提早问题。

1）应用多参数命令：若是客户端在很短的工夫内发送大量的命令过去，会发现响应工夫显著变慢，这因为前面命令始终在期待队列中后面大量命令执行结束。有个办法能够改善提早问题，就是通过单命令多参数的模式取代多命令单参数的模式。举例来说，循环应用LSET命令去增加1000个元素到list构造中，是性能比拟差的一种形式，更好的做法是在客户端创立一个1000元素的列表，用单个命令LPUSH或RPUSH，通过多参数结构模式一次性把1000个元素发送的Redis服务上。上面的表格是Redis的一些操作命令，有单个参数命令和反对多个参数的命令，通过这些命令可尽量减少应用多命令的次数。

2）管道命令：另一个缩小多命令的办法是应用管道(pipeline)，把几个命令合并一起执行，从而缩小因网络开销引起的提早问题。因为10个命令独自发送到服务端会引起10次网络提早开销，应用管道会一次性把执行后果返回，仅须要一次网络提早开销。Redis自身反对管道命令，大多数客户端也反对，假使以后实例提早很显著，那么应用管道去升高提早是十分无效的。

3）防止操作大汇合的慢命令：如果命令解决频率过低导致延迟时间减少，这可能是因为应用了高工夫复杂度的命令操作导致，这意味着每个命令从汇合中获取数据的工夫增大。 所以缩小应用高工夫简单的命令，能显著的进步的Redis的性能。上面的表格是高工夫复杂度命令的列表，其详细描述了命令的属性，有这助于高效正当的、最优化的应用这些命令(如果不得不应用的话)，以进步Redis性能。

延迟时间

Redis的提早数据是无奈从info信息中获取的。假使想要查看延迟时间，能够用 Redis-cli工具加--latency参数运行，如:

Redis-cli --latency -h 127.0.0.1 -p 6379

其host和port是Redis实例的ip及端口。因为以后服务器不同的运行状况，延迟时间可能有所误差，通常1G网卡的延迟时间是200s。

以毫秒为单位测量Redis的响应延迟时间，楼主本机的提早是300s：

跟踪Redis提早性能

Redis之所以这么风行的次要起因之一就是低提早个性带来的高性能，所以说解决提早问题是进步Redis性能最间接的方法。拿1G带宽来说，若是延迟时间远高于200s，那显著是呈现了性能问题。 尽管在服务器上会有一些慢的IO操作，但Redis是单核承受所有客户端的申请，所有申请是按良好的程序排队执行。因而若是一个客户端发过来的命令是个慢操作，那么其余所有申请必须期待它实现后能力继续执行。

应用提早命令进步性能

一旦确定延迟时间是个性能问题后，这里有几个方法能够用来剖析解决性能问题。

1. 应用slowlog查出引发提早的慢命令：

Redis中的slowlog命令能够让咱们疾速定位到那些超出指定执行工夫的慢命令，默认状况下命令若是执行工夫超过10ms就会被记录到日志。slowlog只会记录其命令执行的工夫，不蕴含io往返操作，也不记录单由网络提早引起的响应慢。

通常1gb带宽的网络提早，预期在200s左右，假使一个命令仅执行工夫就超过10ms，那比网络提早慢了近50倍。 想要查看所有执行工夫比较慢的命令，能够通过应用Redis-cli工具，输出slowlog get命令查看，返回后果的第三个字段以奥妙位单位显示命令的执行工夫。如果只须要查看最初10个慢命令，输出slowlog get 10即可。 对于怎么定位到是由慢命令引起的提早问题，可查看total_commands_processed介绍章节。

图中字段别离意思是：

  • 1=日志的惟一标识符
  • 2=被记录命令的执行工夫点，以 UNIX 工夫戳格局示意
  • 3=查问执行工夫，以微秒为单位。例子中命令应用54毫秒。
  • 4= 执行的命令，以数组的模式排列。残缺命令是config get *。

假使你想自定义慢命令的规范，能够调整触发日志记录慢命令的阀值。若是很少或没有命令超过10ms，想升高记录的阀值，比方5毫秒，可在Redis-cli工具中输出上面的命令配置：

config set slowlog-log-slower-than 5000

也能够在Redis.config配置文件中设置，以奥妙位单位。

2.监控客户端的连贯：

因为Redis是单线程模型(只能应用单核)，来解决所有客户端的申请， 但因为客户端连接数的增长，解决申请的线程资源开始升高调配给单个客户端连贯的解决工夫，这时每个客户端须要破费更多的工夫去期待Redis共享服务的响应。

这种状况下监控客户端连接数是十分重要的，因为客户端创立连接数的数量可能超出预期的数量，也可能是客户端端没有无效的开释连贯。在Redis-cli工具中输出info clients能够查看到以后实例的所有客户端连贯信息。如下图，第一个字段(connected_clients)显示以后实例客户端连贯的总数：

Redis默认容许客户端连贯的最大数量是10000。若是看到连接数超过5000以上，那可能会影响Redis的性能。假使一些或大部分客户端发送大量的命令过去，这个数字会低的多。

3.限度客户端连接数：

自Redis2.6当前，容许使用者在配置文件(Redis.conf)maxclients属性上批改客户端连贯的最大数，也能够通过在Redis-cli工具上输出config set maxclients 去设置最大连接数。依据连接数负载的状况，这个数字应该设置为预期连接数峰值的110%到150之间，若是连接数超出这个数字后，Redis会回绝并立即敞开新来的连贯。

通过设置最大连接数来限度非预期数量的连接数增长，是十分重要的。另外，新连贯尝试失败会返回一个谬误音讯，这能够让客户端晓得，Redis此时有非预期数量的连接数，以便执行对应的解决措施。 上述二种做法对管制连接数的数量和持续保持Redis的性能最优是十分重要的，

4.增强内存治理：

较少的内存会引起Redis延迟时间减少。如果Redis占用内存超出零碎可用内存，操作系统会把Redis过程的一部分数据，从物理内存替换到硬盘上，内存替换会显著的减少延迟时间。对于怎么监控和缩小内存应用，可查看used_memory介绍章节。

5. 性能数据指标：

剖析解决Redis性能问题，通常须要把延迟时间的数据变动与其余性能指标的变动相关联起来。命令解决总数降落的产生可能是由慢命令阻塞了整个零碎，但如果命令解决总数的减少，同时内存使用率也减少，那么就可能是因为内存替换引起的性能问题。

对于这种性能指标相关联的剖析，须要从历史数据上来察看到数据指标的重要变动，此外还能够察看到单个性能指标相关联的所有其余性能指标信息。这些数据能够在Redis上收集，周期性的调用内容为Redis info的脚本，而后剖析输入的信息，记录到日志文件中。当提早发生变化时，用日志文件配合其余数据指标，把数据串联起来排查定位问题。

内存碎片率

info信息中的mem_fragmentation_ratio给出了内存碎片率的数据指标，它是由操零碎调配的内存除以Redis调配的内存得出：

used_memory和used_memory_rss数字都蕴含的内存调配有：

  • 用户定义的数据：内存被用来存储key-value值。
  • 外部开销： 存储外部Redis信息用来示意不同的数据类型。

used_memory_rss的rss是Resident Set Size的缩写，示意该过程所占物理内存的大小，是操作系统调配给Redis实例的内存大小。除了用户定义的数据和外部开销以外，used_memory_rss指标还蕴含了内存碎片的开销，内存碎片是由操作系统低效的调配/回收物理内存导致的。

操作系统负责调配物理内存给各个利用过程，Redis应用的内存与物理内存的映射是由操作系统上虚拟内存治理分配器实现的。

举个例子来说，Redis须要调配间断内存块来存储1G的数据集，这样的话更无利，但可能物理内存上没有超过1G的间断内存块，那操作系统就不得不应用多个不间断的小内存块来调配并存储这1G数据，也就导致内存碎片的产生。

内存分配器另一个简单的层面是，它常常会事后调配一些内存块给援用，这样做会使放慢应用程序的运行。

了解资源性能

跟踪内存碎片率对了解Redis实例的资源性能是十分重要的。内存碎片率稍大于1是正当的，这个值示意内存碎片率比拟低，也阐明redis没有产生内存替换。但如果内存碎片率超过1.5，那就阐明Redis耗费了理论须要物理内存的150%，其中50%是内存碎片率。若是内存碎片率低于1的话，阐明Redis内存调配超出了物理内存，操作系统正在进行内存替换。内存替换会引起非常明显的响应提早，可查看used_memory介绍章节。

上图中的0.99即99%。

用内存碎片率预测性能问题

假使内存碎片率超过了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 memory能够查看下面三个指标的信息：

在重启服务器之前，须要在Redis-cli工具上输出shutdown save命令，意思是强制让Redis数据库执行保留操作并敞开Redis服务，这样做能保障在执行Redis敞开时不失落任何数据。 在重启后，Redis会从硬盘上加载长久化的文件，以确保数据集继续可用。

2.限度内存替换：

如果内存碎片率低于1，Redis实例可能会把局部数据交换到硬盘上。内存替换会重大影响Redis的性能，所以应该减少可用物理内存或缩小实Redis内存占用。 可查看used_memory章节的优化倡议。

3.批改内存分配器：

Redis反对glibc’s malloc、jemalloc11、tcmalloc几种不同的内存分配器，每个分配器在内存调配和碎片上都有不同的实现。

不倡议一般管理员批改Redis默认内存分配器，因为这须要齐全了解这几种内存分配器的差别，也要从新编译Redis。这个办法更多的是让其理解Redis内存分配器所做的工作，当然也是改善内存碎片问题的一种方法。

回收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分片
  • d. 虚构桶分片

总结

对于开发者来说，Redis是个速度十分快的key-value内存数据库，并提供了不便的API接口。为了最好最优的应用Redis，须要了解哪些因素能影响到Redis性能，哪些数据指标能帮忙咱们防止性能陷阱。 通过本篇，能了解Redis中的重要性能指标，怎么查看，更重要的是怎么利用这些数据排查解决Redis性能问题。

本篇博客次要翻译了一电子书的两头15页，电子书地址是：

https://www.datadoghq.com/wp-...

楼主翻译程度无限，如有谬误之处请多多包涵，也欢送指出交换，心愿本文对大家有所帮忙。

作者：蘑菇学生\
出处：http://mushroom.cnblogs.com/

近期热文举荐：

1.600+ 道 Java面试题及答案整顿(2021最新版)

2.终于靠开源我的项目弄到 IntelliJ IDEA 激活码了，真香！

3.阿里 Mock 工具正式开源，干掉市面上所有 Mock 工具！

4.Spring Cloud 2020.0.0 正式公布，全新颠覆性版本！

5.《Java开发手册（嵩山版）》最新公布，速速下载！

感觉不错，别忘了顺手点赞+转发哦！