近期遇一个省的数据库说总是繁忙，idle很小，在凌晨稍微跑几个比较大的统计脚本，idle就出现0的情况，导致业务发生堵塞。

经过连续几天的观察，发现cpu曲线大致如下：

2008年11月18日：

和白鳝交流了一下，老白说cpu的user%比例过高可能是由于buffer get比较高的sql引起。可以重点找一下statspack中buffer get比较高的语句。

根据sar出来的结果，查看对应时间段的statspack：

首先查了hash value为1460516408和2446775708的sql，因为这2个sql的执行次数不高，但是单次执行的消耗很高，查询后发现2个sql的consistent gets有47万。与开发沟通后，该sql的执行计划已经无法改变，但是由于是通过时间点触发，可以将该sql的执行时间延迟到6点之后执行。

同时hash value为3767922078之类的sql由于执行太过于频繁，要求该进程的执行频率是否能够降低一些？但是该进程由于涉及状态同步，如果降低频率会引起用户投诉，暂时无法处理该sql。

待调整后，继续观察一天。发现晚上的曲线还是大致相仿：

2008年11月19日：

继续观察对应时间段的statspack：

发现consistent gets很高的那几个sql已经不再出现，但是为何user的比例还是很高呢？

此时，突然发现了执行很频繁的几个sql，cpu time（s）有300多秒！！如hash value 3582277248、3767922078这几个sql的cpu time比昨天调整的consistent gets 还高！！

其实昨天查的时候，也注意过这几个sql，这几个sql虽然是走全表扫描，不过执行的速度很快：

buffer get部分中cpu time这么高，估计是这几个sql影响了。查询了一下该sql在别的省的执行计划，发现是走PK索引的。这个省的主键不知道被谁删除掉了！！

建立PK后，发现user一下子就下去了。

总结：遇到cpu的user高问题，如果没有enqueue，latch free之类的等待，仅仅是cpu time的等待，看statspack 中buffer get中的cpu time(s)高的sql很重要。

作者：Fenng 发布在 dbanotes.net.

这是前一段时间投稿给《程序员》的一篇文章。标题中的"道"有些大了，您可以理解为"门道"的"道"。一家之言，妄自言道，诚可笑也。

什么是网站运维(Web operations) ？运维，绝不是某些人眼中安装系统、做几根网线那么简单? 除去应用开发和业务运营之外的保障网站能运转的事儿都可能是运维工作的职责范围。运维的工作包括(但不限于) 软硬件部署、网络管理、应用程序维护、安全、容量规划、故障修复等等。

运维，有别于"运营"。在中文的语境中，运营更多和业务结合在一起的。而运维，则是偏向技术层面。

任何一个成功的站点都离不开一只优秀的运维团队，尽管他们更多时候隐身在网站背后不为人知。

网站可用性

所谓网站可用性(availability)也即网站正常运行时间的百分比，这是每个运营团队最主要的 KPI (Key Performance Indicators ，关键业绩指标)。对于 Web 站点来说，传统的那个 24x7 的说法已经不是很适用了，现在业界更倾向用 N 个9 来量化可用性， 最常说的就是类似 "4个9(也就是99.99%)" 的可用性。看一下表 1 能更为直观一些。

根据墨菲定理的推论，世界上没有 100% 可靠的 Web站点(除非不运行)。业界网站的可用性都是多少？引人注目的 Web 新贵 Twitter (http://twitter.com)， 2008 年前四个月的可用性只有 98.72%，有 37小时 16分钟不能提供服务，连2个9 都达不到，甚至还没达到"基本可用"状态。电子商务巨头 eBay 2007 年的可用性是 99.94%，考虑到 eBay 站点的规模与应用的复杂程度，这是个很不错可用性指标了。Web 应用类型决定了不同的站点对可用性的依赖性是不同的。 要知道 4 个 9 的可用性实际上是很难实现的目标。至于 5 个9 的 Web 站点，一半靠内功，另一半恐怕是要靠点运气。

(图1 维基百科网站的一台数据库服务器的可用情况报告, 由Nagios的监控得到的)

多数情况下，网站可用性会是 SLA （Service Level Agreement, 服务水平协议) 中的一个重要度量指标，也是运维团队向自己的客户(更多是公司老板)的正式承诺。可用性是能够持续改进的东西，KPI 制定者切不可狮子大开口，企图一步登天，拍拍脑袋提一些不太切实的指标。运维团队对可用性的承诺也不能开些空头支票，到头来两头难看。值得强调的是，如果是做第三方托管，更需要明确 SLA，明了第三方的服务能力，否则，费尽了九牛二虎之力终于保证了软硬件网络等环节都没问题了，IDC 却频繁断电或者IDC 出口网络不可用，这也绝对做不到预期的高可用性。

提高可用性的一些常规策略有消除单点，部署冗余设备(或集群)，配置带外管理网络等，对可用性要求不高的网站这些可能足够了。如果要提供更高的可用性，比如 4 个 9 甚至 5 个9，就不是简单靠硬件就能做到的事情，还需要建立完善的流程制度、建立变更机制、提升事故响应速度等。正所谓是"没有最高可用，只有更高可用性"。

一般来说，所有的网站运维人员都在追求网站的更高级别的高可用性，但是必须注意，这是以额外的软硬件投入、更多的人力成本为代价的。成本与可用性之间也请做到良好的平衡，盲目追求高可用性是不可取的。

(补充：Twitter 的可用性现在已经有了很大提升，但是可以看到，可用性不佳并非一个网站的杀手，只要产品对用户足够友好，足够有粘度，足够不可或缺，那么可用性并非是第一要追求的运维目标。有些运维人员被 Amazon 的某年圣诞节期间宕机所造成的影响埋下心理阴影，其实没那么可怕，如果真的觉得可怕，那么你可能被一些厂商销售人员洗脑了。)

未完待续: 下一篇《监控与报警》

相关文章|Related Articles

• 国外 Web 站点字体是否都符合"中国国情"? - Feb 9, 2006
• OutfoxBot 是谁家的爬虫? - Jul 25, 2006
• 卓越(Joyo)与 Amazon 接轨后的'智能' - Oct 8, 2006
• Web 2.0 站点扩展性问题随感 - Apr 11, 2007

评论数(4)|添加评论 | 最近作者还说了什么? Follow Fenng@Twitter

本文网址：http://www.dbanotes.net/web/web_operations_availability.html

DBA Notes 理念: 用最简约的技术取得最大的收益...

用这些只能体现中老年人审美情趣的照片来宣传，评弹之落伍也就理所当然的了。我是无法想象，有年轻人看到那些照片会去喜欢某个演员，或进书场听上个把小时。

一种艺术，如果不能吸引年轻人，总是没出息的，我们不能指望这些年轻人有一天也会成为老人。但很多人并不以为然，他们只知道说，年轻人不懂。

那天，一位刚从评校毕业的女孩也在旁边。女孩长的不错，打扮和神情也很“非主流”。师傅在台上拍照，她在下面看着。我问她，喜欢这样的照片吗？她笑笑，然后悄悄说道，“好傻，土死了。拍一张玩玩还可以，怎么可以老是这样拍呢？”

她的回答不但如我所料，而且很合我的心意。我告诉她，知道为什么听一次评弹只要5块钱，而听一次流行歌曲的演唱会需要500块吗？因为现在的评弹听众都是老年人，没有年轻人，只有年轻人才肯花大价钱。想当年可不是这样，你师傅的师傅的师傅可是真正的超级流行偶像啊，开的是哈雷，抽的是雪茄，到香港演出一次，没有几根金条是请不动的，为什么啊？和现在的流行歌手一样，听众都是年轻人。那现在为什么就不行了呢？就是让这帮人给傻掉的！昆曲这些年开始香骚起来了，还不是因为白先勇给《牡丹亭》带来了新的理念和包装？年轻人喜欢上了，也就热闹起来了。至于到底有几个人懂，那并不重要。买票去听艾薇儿音乐会的，又有几个是听得懂英语的呢？

和其他传统曲艺想比，我觉得对评弹动手术要相对容易些，因为它不象一般戏曲那样强调“程式”要求，本身就比较活络，只要牢牢抓住它区别于其他曲艺的最根本的东西，怎么改变都可以。那么，评弹最核心的特征是什么呢？就是我们经常讲的“说、噱、弹、唱”四个字，后来，蒋月泉先生又加了一个“演”字。其中，又以“说”最为重要，乃典型的中国式叙事方式。只要保留了这些精髓，至于是否一定要穿旗袍长衫，是否一定要用苏州方言，并不重要。也只有形式放开了，内容才能放开，可以表现的余地才能真正的宽广起来。

我对女孩说，不要急，你先跟你师傅好好学，打好基本功，特别是“说”，一定要学会如何吸引观众，调动观众。等经验丰富了，你再拜我为师，我帮你写本子，咱再也不说武松红楼梦这些连咱自己都不喜欢的东西了。咱们说“正龙拍虎”。评弹演员也是演员，我很看好你哟。

女孩吧唧吧唧两只大眼睛，然后抬手在嘴巴下打了一个“V”字，喊了一句“耶”！确实很有前途的一副样子，评弹的未来就靠这帮90后的小赤佬了。

小七：时代周报创刊词点评

《时代周刊》创刊词

前一篇转的体系架构的文章有提起Squid 。它相当于在浏览器和Web服务器之间的缓存代理服务器，可以缓存Web服务器上的网页图片文件等内容和资源。

效果图类似这样，Squid起着”前端页面”缓存的作用。

今天下载后简单配置，果然cache的效果不错。

C:\perl accessHTML.pl <— disable Squid
start at 2008/11/20 19:51:50
End at 2008/11/20 19:53:49
Total elasped time is 119 seconds

C:\perl accessHTML.pl <— enalbe Squid by proxy
start at 2008/11/20 20:03:24
End at 2008/11/20 20:03:59
Total elasped time is 35 seconds

可以看到使用了Squid进行缓存后,网页访问时间确实有很大改进。

简单测试perl脚本

只比上次的测试，增加了proxy选择是否使用Squid的网页缓存代理服务

#!/usr/bin/perl
use Time::Local;
use LWP::UserAgent;

my $endtime;
my $starttime;
my $elaspedtime;

$starttime = time();

my @array=(localtime)[5,4,3,2,1,0];
$array[0]+=1900;
$array[1]+=1;
my $nowtime=sprintf(”%04u/%02u/%02u %02u:%02u:%02u”,@array);
print(”start at “.”$nowtime\n”);

for($i = 1; $i < 30; $i++) {

$url=”http://www.yumianfeilong.com/”;
$ua = LWP::UserAgent->new();
$ua->proxy([’http’] => “http://127.0.0.1:3128/”);

$res=$ua->request( HTTP::Request->new(’GET’,$url));
if ($res->is_success)
{
$countoflines=10000;
$randnum = int(rand($countoflines));
$dmpfile = “htmlfile.$randnum.html”;
open DMPFILE,”>$dmpfile” or die “Can not open and write to $dmpfile”;
print DMPFILE $res->content;
close(DUMPFILE);
unlink(”$dmpfile”);
}
else
{
print (”Error: ” . $res->status_line . “\n”) ;
}
}#end for loop

$endtime = time();

#print “Total elasped time is ” . $endtime - $starttime . ” seconds. \n”;
my @array2=(localtime)[5,4,3,2,1,0];
$array2[0]+=1900;
$array2[1]+=1;
my $nowtime=sprintf(”%04u/%02u/%02u %02u:%02u:%02u”,@array2);
print(”End at “.”$nowtime\n”);
print(”Total elasped time is “);
print(@array2[5] + @array2[4]*60 - @array[5] - @array[4]*60 );
print(” seconds.\n”);

proxy表示我将Squid监听在本地机器的3128端口上。