« 不用cn域名以及不在国内注册域名的原因 | Main | 春节 »

力破困局千万重-技术咨询手记 1

作者:virushuo 发表于 2009-01-12 23:01 最后更新于 2009-01-13 00:01
版权声明:按照by-nc-sa的cc协议可转载,拒绝采用“独家” 授权媒介(含网站和平面媒体)转载、引用、链接,除非获得本人许可。转载时请务必以超链接形式标明文章原始出处和作者信息及本声明。


一 从何开始?


2006年10月,我和tiny创立银杏咨询,开始提供技术咨询服务。到现在,已经2年多了。时间过的真快!

这2年中,我们逐渐开始了站内搜索SAAS服务 ,但是咨询的服务也仍然在做。积累了2年,见过了太多正常的,古怪的,常见的,重复的,白痴的问题,现在,我打算开始慢慢的写出来,给别人参考。

当然,惯例声明。本文所述一切情况,并不来源于某个特定的团体或公司,是我们2年工作经历的组合,也就不用猜测到底是谁了。万一有雷同绝对巧合:D

记得我跟Fenng聊到过,写技术,尤其是优化和架构相关的文章,总显的很无聊。因为懂的人不说也懂,不懂的说了还不懂。新手的php程序员们不分场合的迷恋模版和MVC,而全然不知其所以然。所以后来我那个《让你的网站快100倍》,就没有继续写下去了。还是跟着实际的案例来看,会比较有趣一点,你说呢?

可以说,我们处在一个非常幸运的行业中,因为这个行业发展的太快了,人才缺口实在太大,大到历史上任何行业都没有过的程度。很多公司甚至糟糕到了没办法判断一个人是否能够胜任的地步了。某个公司的创始人跟我说,我们最大的问题是,根本没办法鉴别招聘来的这个程序员是高手还是忽悠。

这就是我们面临的情况。无数的新手,无数的忽悠,就这么草草上阵,开始为无数伟大的构想和商业模型搭建基础。如果不伟大的项目还好,早早就死掉了,也没有后面的问题了。伟大的项目,就会突然碰到瓶颈,这时候,大家都傻了。

我们的客户往往就是这类,他们是伟大的项目,所以他们碰上麻烦了。

“好了,咱们从何开始呢?”,会议桌对面的客户满脸的痛苦,想了半天,说出来这么句话。

我和tiny互相对视了一下,说:“就从你最头疼,影响最大的地方开始吧”。

这是一个媒体网站。按道理来说,媒体网站不大应该碰上性能问题,媒体网站更新量往往并不大,访问量也不大,但是人群比较集中,价值也比较高。这是网站里面活的最潇洒的一类公司,他们用数量小,价值高的pv获得可观的广告收入。对于硬件投入也比较舍得。但是现实总是这么荒唐,这种从来不愁钱的网站,碰上的问题最多。

他们最头疼的问题,就是网站会突然挂掉。但是找不到原因。

好吧,就从这里开始。

背景资料:本网站用java+jsp开发的。基于某古怪的架构(架构的古怪之处随后慢慢说),每天更新量只有几十篇文章。访问量在百万以下的级别。没什么交互。

看起来很简单?清点一下系统拓扑图可不得了,竟然有10多台机器趴在机房里!而且还使用了CDN。饶是如此,仍然摆脱不了3天一小死,5天一大死的噩梦。

我们开始的方法很简单。查log。我们希望通过分析访问log,来获得系统各部分的负载状况,从而进行分析,找出薄弱环节。

log呢?竟然所有的服务器都没有记录log。

很多人认为,记录log会消耗更多的资源。其实并非如此,如果log非常大,比如几个G,确实会让写入的时候变得有一些慢。但是大部分情况下,如果定时清理,或是做了切分,不应该对系统性能造成什么影响。

平时不记录log是可以的,但是很多情况就错过了,将来需要回溯寻找问题的时候,就没有了依据。这很糟糕。google analytics很好,但是它是用来分析统计情况的,不是用来寻找系统问题的。你完全可以用google analytics来代替awstat之类的分析软件,但绝对不能替代原始的log。

针对这个客户的情况,我们记录了几种log。

1 java application server (tomcat/...) 的access log 和error log
2 apache 的access log和error log
3 mysql slow query
4 sar 记录系统活动
5 vmstat 状态 ,没什么现成的工具,我写了个脚本,供参考。


采集这些数据就可以进行初步分析了,修改好了所有配置,部署好了所需要的脚本,剩下的就是等待了。

等待出问题。

我心里偷偷的想,如果客户知道我们从这一天开始盼望着出问题,会不会恨我们.....

相关文章:
blog comments powered by Disqus
CC License. Some rights reserved.
署名·非商业用途·保持一致
本站之所有未作特别说明的内容均使用 创作共用协议.
POWERED_BY_MT_3.2