Embed Size (px)
DESCRIPTION
Citation preview
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 自动化测试原理
模拟前台 JS 代码发送 cgi 请求，并接收返回，纪录响应时间，并分析返回包
实质是一种黑盒集成测试
监控结果存在某种程度的失真
建议在返回包中，提供返回码
立体化监控
LogServer
立体化监控
立体化容量管理体系
Minskzhang 2008-1-20
运营数据分析
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 的性能依赖比较重模块相互独立，容易造成数据不一致
CGI
接入
共享内存CACHE处理
DB接口
DB
接入
共享内存CACHE处理
DB接口
DB
接入
共享内存CACHE处理
DB接口
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处理
DB接口
DB
接入
共享内存+文件二级CACHE处理
DB接口
DB
接入
共享内存CACHE处理
DB接口
DB
日志标题 日志信息 访问计数
R/W
R/WR
W
系统分三个模块：日志信息、日志标题、访问计数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
