恰好看到一些redis需要主要的东西 记下 供参考
原文地址 http://hi.baidu.com/ywdblog/item/1a8c6ed42edf01866dce3fe3
最近在线上实际使用了一些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命令动态设置系统参数(不用重新服务器).假如确实需要重新启动才能生效,则可以通过先在副库配置,然后通过指向将副升级为主.
总体上来说,机器性能和内存比较大,暂时没有发现特别多的问题.