技术头条 - 一个快速在微博传播文章的方式     搜索本站
您现在的位置首页 --> 系统运维 --> redis运维的一些知识点

redis运维的一些知识点

浏览:7228次  出处信息
最近在线上实际使用了一些redis服务,总结下运维的相关知识.

    1:redis的生产机主要为2颗Cpu,8个核心,内存32G,单盘700G的Sata盘.

    

2:存储的数据为博客系统的积分数据.积分代表是用户的发文章积分,发评论积分,登录积分,特点即每天单个用户相关数据至多增加一次,是一个典型的读多写少系统.虽然在这个项目中将redis作为内存系统使用,本质上是落地存储.

    

    

3:redis版本为2.2.5,使用Hashes存储类型.原先积分系统的后端为memcachedb,对比应用的好处就是不用客户端维护一个大的json对象.大概6000万条数据.快照文件dump后大概1.2G.Aof文件大概12G.
注意:线上实际运行二个实例(充分利用Cpu).另外目前该服务器主要运行积分系统的二个实例.

    

4:对于单实例,Redis实际申请的内存4.2G.而操作系统分配的内存为5.5G.这主要是系统Pagesize的原因.对于redis这样的纯内存系统来说,减少数据对象大小和内存大小是长期优化之路,后期也会经常性观察内存变化情况.

    

5:系统运行状况

    基本上系统负载小于1.主要使用了一个Cpu.网络出口流量高峰小于2M.磁盘写入量极少,每秒写入量不到1M.

    二个实例大概每秒1500次.通过info命令和log日志分析(注意避免文件过大)得到了验证.

    6:持久化

    没有启用vm模式,采用Aof方式进行处理,每天定期错开时间运行bgsave,bgrewriteaof进行重写.对于写时复制原理,要注意内存的使用情况,由于线上服务内存实在太大,没有遇到交换的问题.假如实时性不是要求特高的话,其实在dump的时候禁止客户端请求,对于内存的使用将会大大减少.

    7:Dump操作对应系统运行状况

    fork出来的子进程基本95%消耗一个Cpu.磁盘每秒写入量达到200M,假如后续运行多个实例,磁盘可能会成为一个瓶颈.另外观察到Dump的时候客户端使用的时候出现的错误情况比较多(主要是链接的)

    

8:性能

    通过程序记录的日志来看,抛出可能存在的异常点,基本性能能达到毫秒级,但是有部分日志非常异常,程序执行时间大于5秒(非常有规律)

    

9:复制
进行主从复制,基本上就是同步日志,不过这确实符合了主从复制的功能(备份),而数据库其实是错用备份功能为分布式.从官方看到,redis大部分功能可以通过command set命令动态设置系统参数(不用重新服务器).假如确实需要重新启动才能生效,则可以通过先在副库配置,然后通过指向将副升级为主.

    总体上来说,机器性能和内存比较大,暂时没有发现特别多的问题.

建议继续学习:

  1. redis源代码分析 - persistence    (阅读:30930)
  2. Redis消息队列的若干实现方式    (阅读:10572)
  3. 基于Redis构建系统的经验和教训    (阅读:9068)
  4. 浅谈redis数据库的键值设计    (阅读:8138)
  5. redis在大数据量下的压测表现    (阅读:7242)
  6. Redis和Memcached的区别    (阅读:6505)
  7. Redis作者谈Redis应用场景    (阅读:6434)
  8. redis 运维实际经验纪录之一    (阅读:6334)
  9. 记Redis那坑人的HGETALL    (阅读:6187)
  10. Redis内存存储结构分析    (阅读:6118)
QQ技术交流群:445447336,欢迎加入!
扫一扫订阅我的微信号:IT技术博客大学习
<< 前一篇:Super Smack
© 2009 - 2024 by blogread.cn 微博:@IT技术博客大学习

京ICP备15002552号-1