Redis 常见的性能问题和解决方法 - 温柔一刀 - ITeye技术网站
博客分类：
1.Master写内存快照，save命令调度rdbSave函数，会阻塞主线程的工作，当快照比较大时对性能影响是非常大的，会间断性暂停服务，所以Master最好不要写内存快照。
2.Master AOF持久化，如果不重写AOF文件，这个持久化方式对性能的影响是最小的，但是AOF文件会不断增大，AOF文件过大会影响Master重启的恢复速度。
3.Master调用BGREWRITEAOF重写AOF文件，AOF在重写的时候会占大量的CPU和内存资源，导致服务load过高，出现短暂服务暂停现象。
下面是我的一个实际项目的情况，大概情况是这样的：一个Master，4个Slave，没有Sharding机制，仅是读写分离，Master负责写入操作和AOF日志备份，AOF文件大概5G，Slave负责读操作，当Master调用BGREWRITEAOF时，Master和Slave负载会突然陡增，Master的写入请求基本上都不响应了，持续了大概5分钟，Slave的读请求过也半无法及时响应，Master和Slave的服务器负载图如下：
Master Server load：
Slave server load：
上面的情况本来不会也不应该发生的，是因为以前Master的这个机器是Slave，在上面有一个shell定时任务在每天的上午10点调用BGREWRITEAOF重写AOF文件，后来由于Master机器down了，就把备份的这个Slave切成Master了，但是这个定时任务忘记删除了，就导致了上面悲剧情况的发生，原因还是找了几天才找到的。
将no-appendfsync-on-rewrite的配置设为yes可以缓解这个问题，设置为yes表示rewrite期间对新写操作不fsync，暂时存在内存中，等rewrite完成后再写入。最好是不开启Master的AOF备份功能。
4.Redis主从复制的性能问题，第一次Slave向Master同步的实现是：Slave向Master发出同步请求，Master先dump出rdb文件，然后将rdb文件全量传输给slave，然后Master把缓存的命令转发给Slave，初次同步完成。第二次以及以后的同步实现是：Master将变量的快照直接实时依次发送给各个Slave。不管什么原因导致Slave和Master断开重连都会重复以上过程。Redis的主从复制是建立在内存快照的持久化基础上，只要有Slave就一定会有内存快照发生。虽然Redis宣称主从复制无阻塞，但由于磁盘io的限制，如果Master快照文件比较大，那么dump会耗费比较长的时间，这个过程中Master可能无法响应请求，也就是说服务会中断，对于关键服务，这个后果也是很可怕的。
以上1.2.3.4根本问题的原因都离不开系统io瓶颈问题，也就是硬盘读写速度不够快，主进程 fsync()/write() 操作被阻塞。
5.单点故障问题，由于目前Redis的主从复制还不够成熟，所以存在明显的单点故障问题，这个目前只能自己做方案解决，如：主动复制，Proxy实现Slave对Master的替换等，这个也是Redis作者目前比较优先的任务之一，作者的解决方案思路简单优雅，详情可见 Redis Sentinel design draft 。
1.Master最好不要做任何持久化工作，包括内存快照和AOF日志文件，特别是不要启用内存快照做持久化。
2.如果数据比较关键，某个Slave开启AOF备份数据，策略为每秒同步一次。
3.为了主从复制的速度和连接的稳定性，Slave和Master最好在同一个局域网内。
4.尽量避免在压力较大的主库上增加从库
5.为了Master的稳定性，主从复制不要用图状结构，用单向链表结构更稳定，即主从关系为：Master&--Slave1&--Slave2&--Slave3.......，这样的结构也方便解决单点故障问题，实现Slave对Master的替换，也即，如果Master挂了，可以立马启用Slave1做Master，其他不变。
今天暂时写这么多吧，以后再补充。
浏览 22706
论坛回复 /
(16 / 10624)
最近也在研究redis，如何在项目中使用呢？感觉网上的资料太少了。。。网上资料已经很多了，这里是中文资料聚集地：/html/3537.html
浏览: 716777 次
来自: 上海
必须用ie浏览器
我也出现与楼上相同的问题。查了一些资料，描述的跟楼主的博文差不 ...
&div class=&quote_title ...
最近也在研究redis，如何在项目中使用呢？感觉网上的资料太少 ...
lz好人呀，谢谢分享！SAP HANA内存数据库与oracle数据库的性能比较
&&&&&&&& ORACLE数据库
&&&&&&&& 传统磁盘数据库的基本访问模式。为了提高性能在产品和应用之间会加入缓存的内存区域。传统数据库性能瓶颈主要出现在一个是内存不够，一个IO读写效率太低。oracle 体系结构中，数据库实例的系统全局区SGA（System global area） 是核心的组成部分，它是一组共享的内存结构，里面存储了oracle数据库实例（instance）的数据和控制文件信息。
&&&&&&& SGA主要包括以下几部分：共享池，数据缓冲区，大型池，Java池，日志缓冲区。如果每次执行一个操作时，Oracle都必须从磁盘读取所有数据块并在改变它之后又必须把每一块写入磁盘，显然效率会非常低。数据缓冲区存放需要经常访问的数据，供所有用户使用。修改数据时，首先从数据文件中取出数据，存储在数据缓冲区中，修改/插入数据也存储在缓冲区中，commit或DBWR进程的其他条件引发时，数据被写入数据文件。而SGA的内存是极其有限的，所以SGA是影响Oracle数据库性能的重要因素.
&&&&&& SAP HANA内存数据库，拥有大量的内存，在数据库启动过程中把数据从磁盘上加载到内存中，而对数据进行操作也是数据是先不存储到磁盘上(Disk)(数据操作会有相应的日志保存)，存储在内存中，MVCC:(Multi Version Concurrency Control)用来控制内存数据的一致性，而后台savepoint定时的把内存中数据的修改从内存中写入磁盘。内存数据库并不是实时的把数据更新到磁盘上，这样就减少很多磁盘的IO操作，而数据有加载到内存中，内存存储读取的性能远高于磁盘存储。读写操作都针对内存进行，不再直接与磁盘数据库交互，相当于是一种异步操作，显然，异步操作使得前端的写操作显得更快。虽然oracle的读写操作也有针对内存进行，但由于SGA的内存有限，遇到大数据量时，性能相比内存数据库就相差很远。
(编辑：cindy liu )
------分隔线----------------------------
您有可能感兴趣的文章
栏目推荐文章
Copyright &
All Rights Reserved.
网站声明：SAP和SAP LOGO是SAP AG公司商标，SAP中文学习网与SAP并无任何关联。您的位置：
Redis常见的性能问题和解决方法
日 07:05:33　|　作者：温柔一刀　|　来源：ITeye
摘要：本文介绍了DBA在实际工作中遇到的一些Redis问题以及对应的规避和解决方案，如果你也在用Redis，那么可能其中有一些经验可供参考。
1.写内存快照，save命令调度rdbSave函数，会阻塞主线程的工作，当快照比较大时对性能影响是非常大的，会间断性暂停服务，所以Master最好不要写内存快照。
2.Master AOF持久化，如果不重写AOF文件，这个持久化方式对性能的影响是最小的，但是AOF文件会不断增大，AOF文件过大会影响Master重启的恢复速度。
3.Master调用BGREWRITEAOF重写AOF文件，AOF在重写的时候会占大量的CPU和内存资源，导致服务load过高，出现短暂服务暂停现象。
下面是我的一个实际项目的情况，大概情况是这样的：一个Master，4个Slave，没有Sharding机制，仅是读写分离，Master负责写入操作和AOF日志备份，AOF文件大概5G，Slave负责读操作，当Master调用BGREWRITEAOF时，Master和Slave负载会突然陡增，Master的写入请求基本上都不响应了，持续了大概5分钟，Slave的读请求过也半无法及时响应，Master和Slave的服务器负载图如下：
Master Server load：
Slave server load：
上面的情况本来不会也不应该发生的，是因为以前Master的这个机器是Slave，在上面有一个shell定时任务在每天的上午10点调用BGREWRITEAOF重写AOF文件，后来由于Master机器down了，就把备份的这个Slave切成Master了，但是这个定时任务忘记删除了，就导致了上面悲剧情况的发生，原因还是找了几天才找到的。
将no-appendfsync-on-rewrite的配置设为yes可以缓解这个问题，设置为yes表示rewrite期间对新写操作不fsync，暂时存在内存中，等rewrite完成后再写入。最好是不开启Master的AOF备份功能。
4.主从复制的性能问题，第一次Slave向Master同步的实现是：Slave向Master发出同步请求，Master先dump出rdb文件，然后将rdb文件全量传输给slave，然后Master把缓存的命令转发给Slave，初次同步完成。第二次以及以后的同步实现是：Master将变量的快照直接实时依次发送给各个Slave。不管什么原因导致Slave和Master断开重连都会重复以上过程。Redis的主从复制是建立在内存快照的持久化基础上，只要有Slave就一定会有内存快照发生。虽然Redis宣称主从复制无阻塞，但由于Redis使用单线程服务，如果Master快照文件比较大，那么第一次全量传输会耗费比较长时间，且文件传输过程中Master可能无法提供服务(+本站微信networkworldweixin)，也就是说服务会中断，对于关键服务，这个后果也是很可怕的。
以上1.2.3.4根本问题的原因都离不开系统io瓶颈问题，也就是硬盘读写速度不够快，主进程 fsync()/write() 操作被阻塞。
5.单点故障问题，由于目前Redis的主从复制还不够成熟，所以存在明显的单点故障问题，这个目前只能自己做方案解决，如：主动复制，Proxy实现Slave对Master的替换等，这个也是Redis作者目前比较优先的任务之一，作者的解决方案思路简单优雅，详情可见 Redis Sentinel design draft http://redis.io/topics/sentinel-spec。
1.Master最好不要做任何持久化工作，包括内存快照和AOF日志文件，特别是不要启用内存快照做持久化。
2.如果数据比较关键，某个Slave开启AOF备份数据，策略为每秒同步一次。
3.为了主从复制的速度和连接的稳定性，Slave和Master最好在同一个局域网内。
4.尽量避免在压力较大的主库上增加从库
5.为了Master的稳定性，主从复制不要用图状结构，用单向链表结构更稳定，即主从关系为：Master&--Slave1&--Slave2&--Slave3.......，这样的结构也方便解决单点故障问题，实现Slave对Master的替换，也即，如果Master挂了，可以立马启用Slave1做Master，其他不变。
[责任编辑：软件频道 ]
正在加载...
我也说几句
汇编一周来国内外网络和IT行业发生的焦点新闻，精挑细选，第一时间推送独家采写的深度报道和热点专题，深入挖掘新闻事件背后的故事，剖析新闻事件的来龙去脉，让读者准确把握业界的发展态势。
汇集存储频道每周精华内容，让您在最短的时间内，以最便捷的方式获取权威的购买指南，专家博客，皆汇聚在此。
定期为您带来深入权威的网络，交换机，路由器，无线，通信领域信息服务，涵盖产品，技术，新闻，应用案例，评测,购买指南，专栏，技巧等多个方面的信息。与企业网络相关的一切，尽在网络通信邮件，您怎可错过？
新一代数据中心建设管理最新信息快递――聚焦新一代绿色数据中心的设计、建设、运营和管理，汇集业界专家与用户的最精粹观点，展示国内外数据中心经典案例！
定期为您带来安全领域权威专业的产品，技术，新闻，应用案例，评测，购买指南等信息，保护您在网络畅游之时不受病毒的威胁，企业运行之际减少安全的风险。一份邮件在手，一份安全在心！
深入、专业关注云计算相关的技术与实践，范围覆盖私有云建设、公有云服务运营、开源云平台发展、重要云服务商动态等领域，面向企业CIO和IT经理提供深度原创报道，以及云计算、云服务领域最新的市场资讯。
汇集软件频道每周精华内容，让您在最短的时间内，以最便捷的方式获取权威的企业软件新闻，SOA，SaaS，BI，ERP，开源技术，产品，技巧等全方面的实用资讯。还犹豫什么，这就开始体验一下吧！
深入、专业关注大数据相关的技术与实践，提供Hadoop、NoSQL等领域的最新技术资讯，定期发布由业界专家撰写的大数据专栏文章，面向企业CIO、IT经理、DBA提供深度原创报道，以及大数据领域的最新市场资讯。
汇集服务器频道每周精华内容，让您在最短的时间内，以最便捷的方式获取权威的服务器虚拟化，刀片服务器，操作系统，大型机，服务器芯片信息，最新最全的服务器技巧，购买指南，专家博客，皆汇聚在此。
网界网网络学院频道，内容涵盖移动互联，技术开发，Web前端，安全，网络通信，云计算，数据中心，存储，服务器，软件等内容。
订阅过的用户，全部取消选择，可取消订阅
网络世界移动客户端网界网微信订阅号博客访问： 56423
博文数量： 71
注册时间：
专注数据库故障诊断，性能优化。
ITPUB论坛APP
ITPUB论坛APP
APP发帖 享双倍积分
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： Linux
原文地址： 作者：
1.性能分析的目的
1）找出系统性能瓶颈（包括硬件瓶颈和软件瓶颈）；
2）提供性能优化的方案（升级硬件？改进系统系统结构？）；
3）达到合理的硬件和软件配置；
4）使系统资源使用达到最大的平衡。（一般情况下系统良好运行的时候恰恰各项资源达到了一个平衡体，任何一项资源的过渡使用都会造成平衡体系破坏，从而造成系统负载极高或者响应迟缓。比如CPU过渡使用会造成大量进程等待CPU资源，系统响应变慢，等待会造成进程数增加，进程增加又会造成内存使用增加，内存耗尽又会造成虚拟内存使用，使用虚拟内存又会造成磁盘IO增加和CPU开销增加）
2.影响性能的因素
1）CPU（cpu的速度与性能很大一部分决定了系统整体的性能，是否使用SMP）
2）内存（物理内存不够时会使用交换内存，使用swap会带来磁盘I0和cpu的开销）
3）硬盘（存储系统）
a.Raid技术使用（RAID0,
RAID1, RAID5, RAID0+1）
b.小文件读写瓶颈是磁盘的寻址（tps），大文件读写的性能瓶颈是带宽
c.Linux可以利用空闲内存作文件系统访问的cache，因此系统内存越大存储系统的性能也越好
4）网络带宽。
3.性能分析的步骤
1)对资源的使用状况进行长期的监控和数据采集（nagios、cacti）
2）使用常见的性能分析工具（vmstat、top、free、iostat等)
3）经验积累
a.应用程序设计的缺陷和数据库查询的滥用最有可能导致性能问题
b.性能瓶颈可能是因为程序差/内存不足/磁盘瓶颈，但最终表现出的结果就是CPU耗尽，系统负载极高，响应迟缓，甚至暂时失去响应
c.物理内存不够时会使用交换内存，使用swap会带来磁盘I0和cpu的开销
d.可能造成cpu瓶颈的问题：频繁执Perl，php，java程序生成动态web；数据库查询大量的where子句、order
by/group by排序……
e.可能造成内存瓶颈问题：高并发用户访问、系统进程多，java内存泄露……
f.可能造成磁盘IO瓶颈问题：生成cache文件，数据库频繁更新，或者查询大表……
4.vmstat详细介绍
vmstat是一个很全面的性能分析工具，可以观察到系统的进程状态、内存使用、虚拟内存使用、磁盘的IO、中断、上下文切换、CPU使用等。对于
Linux 的性能分析，100%理解 vmstat 输出内容的含义，并能灵活应用，那对系统性能分析的能力就算是基本掌握了。
下面是vmstat命令的输出结果：
# vmstat 1 5
对输出解释如下：
a.r列表示运行和等待CPU时间片的进程数，这个值如果长期大于系统CPU个数，就说明CPU资源不足，可以考虑增加CPU；
b.b列表示在等待资源的进程数，比如正在等待I/O或者内存交换等。
a.swpd列表示切换到内存交换区的内存数量（以KB为单位）。如果swpd的值不为0或者比较大，而且si、so的值长期为0，那么这种情况一般不用担心，不会影响系统性能；
b.free列表示当前空闲的物理内存数量（以KB为单位）；
c.buff列表示buffers
cache的内存数量，一般对块设备的读写才需要缓冲；
d.cache列表示page
cached的内存数量，一般作文件系统的cached，频繁访问的文件都会被cached。如果cached值较大，就说明cached文件数较多。如果此时IO中的bi比较小，就说明文件系统效率比较好。
a.si列表示由磁盘调入内存，也就是内存进入内存交换区的数量；
b.so列表示由内存调入磁盘，也就是内存交换区进入内存的数量
c.一般情况下，si、so的值都为0，如果si、so的值长期不为0，则表示系统内存不足，需要考虑是否增加系统内存。
a.bi列表示从块设备读入的数据总量（即读磁盘，单位KB/秒）
b.bo列表示写入到块设备的数据总量（即写磁盘，单位KB/秒）
这里设置的bi+bo参考值为1000，如果超过1000，而且wa值比较大，则表示系统磁盘IO性能瓶颈。
a.in列表示在某一时间间隔中观察到的每秒设备中断数；
b.cs列表示每秒产生的上下文切换次数。
上面这两个值越大，会看到内核消耗的CPU时间就越多。
a.us列显示了用户进程消耗CPU的时间百分比。us的值比较高时，说明用户进程消耗的CPU时间多，如果长期大于50%，需要考虑优化程序啥的。
b.sy列显示了内核进程消耗CPU的时间百分比。sy的值比较高时，就说明内核消耗的CPU时间多；如果us+sy超过80%，就说明CPU的资源存在不足。
c.id列显示了CPU处在空闲状态的时间百分比；
d.wa列表示IO等待所占的CPU时间百分比。wa值越高，说明IO等待越严重。如果wa值超过20%，说明IO等待严重。
e.st列一般不关注，虚拟机占用的时间百分比。
（Linux 2.6.11）
阅读(523) | 评论(0) | 转发(0) |
相关热门文章
给主人留下些什么吧！~~
请登录后评论。更多公众号：rjzlzx金融信息系统质量控制知识的交流、分享、学习平台。最新文章相关作者文章搜狗：感谢您阅读性能测试问题排查一例——网络带宽瓶颈，本文由网友投稿产生，如果侵犯了您的相关权益，请联系管理员。}