redis运维的一些知识点
浏览:7520次 出处信息
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命令动态设置系统参数(不用重新服务器).假如确实需要重新启动才能生效,则可以通过先在副库配置,然后通过指向将副升级为主.
总体上来说,机器性能和内存比较大,暂时没有发现特别多的问题.
建议继续学习:
- redis源代码分析 - persistence (阅读:31231)
- Redis消息队列的若干实现方式 (阅读:10773)
- 基于Redis构建系统的经验和教训 (阅读:9387)
- 浅谈redis数据库的键值设计 (阅读:8351)
- redis在大数据量下的压测表现 (阅读:7443)
- Redis和Memcached的区别 (阅读:6895)
- Redis作者谈Redis应用场景 (阅读:6628)
- redis 运维实际经验纪录之一 (阅读:6535)
- 记Redis那坑人的HGETALL (阅读:6375)
- Redis内存存储结构分析 (阅读:6196)
QQ技术交流群:445447336,欢迎加入!
扫一扫订阅我的微信号:IT技术博客大学习
扫一扫订阅我的微信号:IT技术博客大学习
<< 前一篇:Super Smack
后一篇:流量统计方法分类 >>
文章信息
- 作者:ywdblog 来源: 技术 总结 记录 生活 工作
- 标签: redis 运维
- 发布时间:2011-05-30 13:56:44
建议继续学习
近3天十大热文
- [72] Twitter/微博客的学习摘要
- [64] find命令的一点注意事项
- [63] Go Reflect 性能
- [62] android 开发入门
- [62] IOS安全–浅谈关于IOS加固的几种方法
- [60] 流程管理与用户研究
- [60] Oracle MTS模式下 进程地址与会话信
- [60] 如何拿下简短的域名
- [57] 图书馆的世界纪录
- [57] 【社会化设计】自我(self)部分――欢迎区