系统优化的方向？

系统优化的方向？ 监控对研发的支持 sunshinexiong 2008-01-15

系统优化的驱动力 • 问题 • 监控 • 自我实现和挑战

监控 • 被动式监控 • 运维监控，Port、CPU、Memory、DiskIO、Net IO、FileSize、DiskSize • 主动式监控 • HttpWatch工具 • Cgi自动化测试 • 立体化监控体系 • 运营数据采集

监控邮件、url地址 • http://isd.itil.com • 每天自动邮件，纪录每台设备的运维情况 • 综合负载 • CPU占用率 • 网络流量（出、入） • 网络包（出、入） • Load Average/5min • 磁盘Blockin/out

HttpWatch工具

Cgi自动化测试平台 • http://itil.isd.com • 3.0结果展示

Cgi自动化测试原理 • 模拟前台JS代码发送cgi请求，并接收返回，纪录响应时间，并分析返回包 • 实质是一种黑盒集成测试 • 监控结果存在某种程度的失真 • 建议在返回包中，提供返回码

立体化监控 • LogServer

立体化监控

运营数据分析 isdstat.cm.com

IDC测试平台 idcspeed.oa.com

优化工作基础 • 数据分析 • 举例：猜扑克牌 int func(int x, int y, int z); 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;

如何优化？ 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) … intfunc(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设备越来越多，旧架构需要翻倍增长 • 日志正文同回复的存储在一起

新日志存储 • 日志不再按照QQID存储

谢谢！ Qzone 网管监控：coatizhao、johnzhao Cgi 自动化测试：Ashwang 立体化监控：frankyang、samuelliao 模块间调用：minskzhang Qzone 页面测速：galen、stonehuang Qzone ：stevetang、xiahz

系统优化的方向？

系统优化的方向？

Presentation Transcript