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

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

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 地址

5. HttpWatch 工具

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

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

8. 立体化监控
LogServer

9. 立体化监控
立体化容量管理体系
Minskzhang 2008-1-20

10. 运营数据分析
isdstat.cm.com

11. IDC 测试平台
idcspeed.oa.com

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 设备越来越多，旧架构需要翻倍增长
日志正文同回复的存储在一起

21. 新日志存储
日志不再按照 QQ ID 存储

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