Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

腾讯大讲堂19 系统优化的方向

•Download as PPT, PDF•
•
A
areyouok
1 of 22
sunshinexiong 2008-01-15 系统优化的方向？ 监控对研发的支持
系统优化的驱动力 问题 监控 自我实现和挑战
监控 被动式监控 运维监控， Port 、 CPU 、 Memory 、 Disk IO 、 Net IO 、 FileSize 、 DiskSize 主动式监控 HttpWatch 工具 Cgi 自动化测试 立体化监控体系 运营数据采集
http://isd.itil.com 每天自动邮件，纪录每台设备的运维情况 综合负载 CPU 占用率 网络流量（出、入） 网络包（出、入） Load Average/5min 磁盘 Block in/out 监控邮件、 url 地址
HttpWatch 工具
Cgi 自动化测试平台 http://itil.isd.com 3.0 结果展示
Cgi 自动化测试原理 模拟前台 JS 代码发送 cgi 请求，并接收返回，纪录响应时间，并分析返回包 实质是一种黑盒集成测试 监控结果存在某种程度的失真 建议在返回包中，提供返回码
立体化监控 LogServer
立体化监控
运营数据分析 isdstat.cm.com
IDC 测试平台 idcspeed.oa.com
优化工作基础 数据分析 举例：猜扑克牌 enum card {cardA,card2,card3,card4,card5,card6,card7,card8,card9,card10,cardJ,cardQ,cardK}; enum card i,j,k; for ( i = cardA, i < cardK, i++) for ( j= cardA, j < cardK, j++) for ( k = cardA, k < cardK, k++) if ( 3==func(i,j,k) ) Print(i,j,k), return 0; int func(int x, int y, int z);
如何优化？ func(A,A,A) func(A,A,2) func(A,A,3) func(A,A,4) … func(A,2,A) func(A,2,2) func(A,2,3) func(A,2,4) … func(2,A,A) func(2,A,2) func(2,A,3) func(2,A,4) … int func(int x, int y, int z); enum card {cA,c2,c3,c4,c5,c6,c7,c8,c9,c10,cJ,cQ,cK}; enum card i; int count=0,ret; for ( i = cA, i < cK, i++ ) if ( ret=func(i,i,i) != 0 ) Print(i,ret), 3==count+ret?return 0, count+=ret;
日志优化 新 cache 优化后效果 日志回复 CACHE 上线后， CACHE 高峰期处理的平均延时由 200 － 500ms 左右降至 20ms 左右；目前日志 title 的命中率在 92% 左右，其平均延时在 8ms 左右，以前高峰期在 50-60ms 左右 目前日志 title 还需 8ms 的原因，应该与目前日志 title 的数据有关，每次 DB 的 IO 操作的数据量比较大影响的 后台数据 CACHE 的性能提升，减少了前台 WEB 接入的 httpsvr 的压力，用户体验提升，同时也相应带来了系统稳定性的提升
旧系统结构 模块 日志回复 日志标题 日志计数 优点 CACHE 内存化，提升性能 多进程号段分布处理 业务异步化 缺点 CACHE 量有限，命中率低，对 DB 的性能依赖比较重 模块相互独立，容易造成数据不一致
现网数据分析 数据量 日志标题 cache 10 台 约 69G 命中率：约 90% DB 5 台 约 340G 日志回复 cache 20 台 约 68G 命中率：约 50% DB 20 台 约 9T 日志计数 cache 10 台 约 122G 命中率：约 100% DB 4 台 约 100G 访问量 日志标题 高峰期： 7100 次 / 秒 日志回复 高峰期： 5000 次 / 秒 日志计数 高峰期： 7000 次 / 秒
新系统结构 系统分三个模块：日志信息、日志标题、访问计数 CGI 层对日志标题、访问计数模块有读 / 写权限；对日志标题模块只有读权限，其数据来源于日志信息模块
新 cache 优化后效果 日志回复 CACHE 上线后， CACHE 高峰期处理的平均延时由 200 － 500ms 左右降至 20ms 左右；目前日志 title 的命中率在 92% 左右，其平均延时在 8ms 左右，以前高峰期在 50-60ms 左右 目前日志 title 还需 8ms 的原因，应该与目前日志 title 的数据有关，每次 DB 的 IO 操作的数据量比较大影响的 后台数据 CACHE 的性能提升，减少了前台 WEB 接入的 httpsvr 的压力，用户体验提升，同时也相应带来了系统稳定性的提升
日志信息模块性能 单台机器 4 个 CACHE ，容纳 6000 万个存储节点， CACHE 数据量为 210G 左右空间，每秒中的处理请求约 900 次（其中读 800/ 写 100 ），平均延时为 100ms ，每分钟内处理超过 1 秒的请求为 32 个，占这分钟内访问约 1/1000 现网布局： 15 台 cache 6 台 DB
日志容量扩容 日志数据几何级数增长，每 12 个月数据容量翻一番 DB 设备越来越多，旧架构需要翻倍增长 日志正文同回复的存储在一起
新日志存储 日志不再按照 QQ ID 存储
谢谢！ Qzone 网管监控： coatizhao 、 johnzhao Cgi 自动化 测试： Ashwang 立 体 化 监 控： frankyang 、 samuelliao 模 块 间 调 用： minskzhang Qzone 页面测速： galen 、 stonehuang Qzone ： stevetang 、 xiahz

More Related Content

腾讯大讲堂19 系统优化的方向

  • 1. sunshinexiong 2008-01-15 系统优化的方向？ 监控对研发的支持
  • 3. 监控 被动式监控 运维监控， Port 、 CPU 、 Memory 、 Disk IO 、 Net IO 、 FileSize 、 DiskSize 主动式监控 HttpWatch 工具 Cgi 自动化测试 立体化监控体系 运营数据采集
  • 4. http://isd.itil.com 每天自动邮件，纪录每台设备的运维情况 综合负载 CPU 占用率 网络流量（出、入） 网络包（出、入） Load Average/5min 磁盘 Block in/out 监控邮件、 url 地址
  • 7. Cgi 自动化测试原理 模拟前台 JS 代码发送 cgi 请求，并接收返回，纪录响应时间，并分析返回包 实质是一种黑盒集成测试 监控结果存在某种程度的失真 建议在返回包中，提供返回码
  • 12. 优化工作基础 数据分析 举例：猜扑克牌 enum card {cardA,card2,card3,card4,card5,card6,card7,card8,card9,card10,cardJ,cardQ,cardK}; enum card i,j,k; for ( i = cardA, i < cardK, i++) for ( j= cardA, j < cardK, j++) for ( k = cardA, k < cardK, k++) if ( 3==func(i,j,k) ) Print(i,j,k), return 0; int func(int x, int y, int z);
  • 13. 如何优化？ func(A,A,A) func(A,A,2) func(A,A,3) func(A,A,4) … func(A,2,A) func(A,2,2) func(A,2,3) func(A,2,4) … func(2,A,A) func(2,A,2) func(2,A,3) func(2,A,4) … int func(int x, int y, int z); enum card {cA,c2,c3,c4,c5,c6,c7,c8,c9,c10,cJ,cQ,cK}; enum card i; int count=0,ret; for ( i = cA, i < cK, i++ ) if ( ret=func(i,i,i) != 0 ) Print(i,ret), 3==count+ret?return 0, count+=ret;
  • 14. 日志优化 新 cache 优化后效果 日志回复 CACHE 上线后， CACHE 高峰期处理的平均延时由 200 － 500ms 左右降至 20ms 左右；目前日志 title 的命中率在 92% 左右，其平均延时在 8ms 左右，以前高峰期在 50-60ms 左右 目前日志 title 还需 8ms 的原因，应该与目前日志 title 的数据有关，每次 DB 的 IO 操作的数据量比较大影响的 后台数据 CACHE 的性能提升，减少了前台 WEB 接入的 httpsvr 的压力，用户体验提升，同时也相应带来了系统稳定性的提升
  • 15. 旧系统结构 模块 日志回复 日志标题 日志计数 优点 CACHE 内存化，提升性能 多进程号段分布处理 业务异步化 缺点 CACHE 量有限，命中率低，对 DB 的性能依赖比较重 模块相互独立，容易造成数据不一致
  • 16. 现网数据分析 数据量 日志标题 cache 10 台 约 69G 命中率：约 90% DB 5 台 约 340G 日志回复 cache 20 台 约 68G 命中率：约 50% DB 20 台 约 9T 日志计数 cache 10 台 约 122G 命中率：约 100% DB 4 台 约 100G 访问量 日志标题 高峰期： 7100 次 / 秒 日志回复 高峰期： 5000 次 / 秒 日志计数 高峰期： 7000 次 / 秒
  • 17. 新系统结构 系统分三个模块：日志信息、日志标题、访问计数 CGI 层对日志标题、访问计数模块有读 / 写权限；对日志标题模块只有读权限，其数据来源于日志信息模块
  • 18. 新 cache 优化后效果 日志回复 CACHE 上线后， CACHE 高峰期处理的平均延时由 200 － 500ms 左右降至 20ms 左右；目前日志 title 的命中率在 92% 左右，其平均延时在 8ms 左右，以前高峰期在 50-60ms 左右 目前日志 title 还需 8ms 的原因，应该与目前日志 title 的数据有关，每次 DB 的 IO 操作的数据量比较大影响的 后台数据 CACHE 的性能提升，减少了前台 WEB 接入的 httpsvr 的压力，用户体验提升，同时也相应带来了系统稳定性的提升
  • 19. 日志信息模块性能 单台机器 4 个 CACHE ，容纳 6000 万个存储节点， CACHE 数据量为 210G 左右空间，每秒中的处理请求约 900 次（其中读 800/ 写 100 ），平均延时为 100ms ，每分钟内处理超过 1 秒的请求为 32 个，占这分钟内访问约 1/1000 现网布局： 15 台 cache 6 台 DB
  • 20. 日志容量扩容 日志数据几何级数增长，每 12 个月数据容量翻一番 DB 设备越来越多，旧架构需要翻倍增长 日志正文同回复的存储在一起
  • 22. 谢谢！ Qzone 网管监控： coatizhao 、 johnzhao Cgi 自动化 测试： Ashwang 立 体 化 监 控： frankyang 、 samuelliao 模 块 间 调 用： minskzhang Qzone 页面测速： galen 、 stonehuang Qzone ： stevetang 、 xiahz