2007/08/05 19:50
上一篇我们从MySpace的发展历程中总结出了数据库和磁盘IO的瓶颈是大型高负载高并发网站系统架构需要解决的问题。
这次我们通过另外一个案例，来看看别人又碰到了什么问题，如果解决的。
这次我们通过另外一个案例，来看看别人又碰到了什么问题，如果解决的。
从LiveJournal后台发展看大规模网站性能优化方法
于敦德 2006-3-16
一、LiveJournal发展历程
LiveJournal是99年始于校园中的项目，几个人出于爱好做了这样一个应用，以实现以下功能：- 博客，论坛
- 社会性网络，找到朋友
- 聚合，把朋友的文章聚合在一起
在上线后，LiveJournal实现了非常快速的增长：
- 2004年4月份：280万注册用户。
- 2005年4月份：680万注册用户。
- 2005年8月份：790万注册用户。
- 达到了每秒钟上千次的页面请求及处理。
- 使用了大量MySQL服务器。
- 使用了大量通用组件。
二、LiveJournal架构现状概况
三、从LiveJournal发展中学习
LiveJournal从1台服务器发展到100台服务器，这其中经历了无数的伤痛，但同时也摸索出了解决这些问题的方法，通过对LiveJournal的学习，可以让我们避免LJ曾经犯过的错误，并且从一开始就对系统进行良好的设计，以避免后期的痛苦。
下面我们一步一步看LJ发展的脚步。
1、一台服务器
一台别人捐助的服务器，LJ最初就跑在上面，就像Google开始时候用的破服务器一样，值得我们尊敬。这个阶段，LJ的人以惊人的速度熟悉的Unix的操作管理，服务器性能出现过问题，不过还好，可以通过一些小修小改应付过去。在这个阶段里LJ把CGI升级到了FastCGI。
最终问题出现了，网站越来越慢，已经无法通过优过化来解决的地步，需要更多的服务器，这时LJ开始提供付费服务，可能是想通过这些钱来购买新的服务器，以解决当时的困境。
毫无疑问，当时LJ存在巨大的单点问题，所有的东西都在那台服务器的铁皮盒子里装着。
2、两台服务器
用付费服务赚来的钱LJ买了两台服务器：一台叫做Kenny的Dell 6U机器用于提供Web服务，一台叫做Cartman的Dell 6U服务器用于提供数据库服务。
LJ有了更大的磁盘，更多的计算资源。但同时网络结构还是非常简单，每台机器两块网卡，Cartman通过内网为Kenny提供MySQL数据库服务。
暂时解决了负载的问题，新的问题又出现了：
- 原来的一个单点变成了两个单点。
- 没有冷备份或热备份。
- 网站速度慢的问题又开始出现了，没办法，增长太快了。
- Web服务器上CPU达到上限，需要更多的Web服务器。
3、四台服务器
又买了两台，Kyle和Stan，这次都是1U的，都用于提供Web服务。目前LJ一共有3台Web服务器和一台数据库服务器。这时需要在3台Web服务器上进行负载均横。
LJ把Kenny用于外部的网关，使用mod_backhand进行负载均横。
然后问题又出现了：
- 单点故障。数据库和用于做网关的Web服务器都是单点，一旦任何一台机器出现问题将导致所有服务不可用。虽然用于做网关的Web服务器可以通过保持心跳同步迅速切换，但还是无法解决数据库的单点，LJ当时也没做这个。
- 网站又变慢了，这次是因为IO和数据库的问题，问题是怎么往应用里面添加数据库呢？
4、五台服务器
又买了一台数据库服务器。在两台数据库服务器上使用了数据库同步(Mysql支持的Master-Slave模式)，写操作全部针对主数据库（通过Binlog，主服务器上的写操作可以迅速同步到从服务器上），读操作在两个数据库上同时进行(也算是负载均横的一种吧)。
实现同步时要注意几个事项：
- 读操作数据库选择算法处理，要选一个当前负载轻一点的数据库。
- 在从数据库服务器上只能进行读操作
- 准备好应对同步过程中的延迟，处理不好可能会导致数据库同步的中断。只需要对写操作进行判断即可，读操作不存在同步问题。
5、更多服务器
有钱了，当然要多买些服务器。部署后快了没多久，又开始慢了。这次有更多的Web服务器，更多的数据库服务器，存在 IO与CPU争用。于是采用了BIG-IP作为负载均衡解决方案。
6、现在我们在哪里：
现在服务器基本上够了，但性能还是有问题，原因出在架构上。
数据库的架构是最大的问题。由于增加的数据库都是以Slave模式添加到应用内，这样唯一的好处就是将读操作分布到了多台机器，但这样带来的后果就是写操作被大量分发，每台机器都要执行，服务器越多，浪费就越大，随着写操作的增加，用于服务读操作的资源越来越少。
由一台分布到两台
最终效果
现在我们发现，我们并不需要把这些数据在如此多的服务器上都保留一份。服务器上已经做了RAID，数据库也进行了备份，这么多的备份完全是对资源的浪费，属于冗余极端过度。那为什么不把数据分布存储呢？
问题发现了，开始考虑如何解决。现在要做的就是把不同用户的数据分布到不同的服务器上进行存储，以实现数据的分布式存储，让每台机器只为相对固定的用户服务，以实现平行的架构和良好的可扩展性。
为了实现用户分组，我们需要为每一个用户分配一个组标记，用于标记此用户的数据存放在哪一组数据库服务器中。每组数据库由一个master及几个slave组成，并且slave的数量在2-3台，以实现系统资源的最合理分配，既保证数据读操作分布，又避免数据过度冗余以及同步操作对系统资源的过度消耗。
由一台（一组）中心服务器提供用户分组控制。所有用户的分组信息都存储在这台机器上，所有针对用户的操作需要先查询这台机器得到用户的组号，然后再到相应的数据库组中获取数据。
这样的用户架构与目前LJ的架构已经很相像了。
在具体的实现时需要注意几个问题：
- 在数据库组内不要使用自增ID，以便于以后在数据库组之间迁移用户，以实现更合理的I/O，磁盘空间及负载分布。
- 将userid，postid存储在全局服务器上，可以使用自增，数据库组中的相应值必须以全局服务器上的值为准。全局服务器上使用事务型数据库InnoDB。
- 在数据库组之间迁移用户时要万分小心，当迁移时用户不能有写操作。
7、现在我们在哪里
问题：
- 一个全局主服务器，挂掉的话所有用户注册及写操作就挂掉。
- 每个数据库组一个主服务器，挂掉的话这组用户的写操作就挂掉。
- 数据库组从服务器挂掉的话会导致其它服务器负载过大。
对于Master-Slave模式的单点问题，LJ采取了Master-Master模式来解决。所谓Master-Master实际上是人工实现的，并不是由MySQL直接提供的，实际上也就是两台机器同时是Master，也同时是Slave，互相同步。
Master-Master实现时需要注意：
- 一个Master出错后恢复同步，最好由服务器自动完成。
- 数字分配，由于同时在两台机器上写，有些ID可能会冲突。
解决方案：
- 奇偶数分配ID，一台机器上写奇数，一台机器上写偶数
- 通过全局服务器进行分配(LJ采用的做法)。
Master-Master模式还有一种用法，这种方法与前一种相比，仍然保持两台机器的同步，但只有一台机器提供服务（读和写），在每天晚上的时候进行轮换，或者出现问题的时候进行切换。
8、现在我们在哪里
现在插播一条广告，MyISAM VS InnoDB。
使用InnoDB：
- 支持事务
- 需要做更多的配置，不过值得，可以更安全的存储数据，以及得到更快的速度。
使用MyISAM：
- 记录日志（LJ用它来记网络访问日志）
- 存储只读静态数据，足够快。
- 并发性很差，无法同时读写数据（添加数据可以）
- MySQL非正常关闭或死机时会导致索引错误，需要使用myisamchk修复，而且当访问量大时出现非常频繁。
9、缓存
去年我写过一篇文章介绍memcached，它就是由LJ的团队开发的一款缓存工具，以key-value的方式将数据存储到分布的内存中。LJ缓存的数据：
- 12台独立服务器（不是捐赠的）
- 28个实例
- 30GB总容量
- 90-93%的命中率（用过squid的人可能知道，squid内存加磁盘的命中率大概在70-80%）
如何建立缓存策略？
想缓存所有的东西？那是不可能的，我们只需要缓存已经或者可能导致系统瓶颈的地方，最大程度的提交系统运行效率。通过对MySQL的日志的分析我们可以找到缓存的对象。
缓存的缺点？
- 没有完美的事物，缓存也有缺点：
- 增大开发量，需要针对缓存处理编写特殊的代码。
- 管理难度增加，需要更多人参与系统维护。
- 当然大内存也需要钱。
10、Web访问负载均衡
在数据包级别使用BIG-IP，但BIG-IP并不知道我们内部的处理机制，无法判断由哪台服务器对这些请求进行处理。反向代理并不能很好的起到作用，不是已经够快了，就是达不到我们想要的效果。
所以，LJ又开发了Perlbal。特点：
- 快，小，可管理的http web 服务器/代理
- 可以在内部进行转发
- 使用Perl开发
- 单线程，异步，基于事件，使用epoll , kqueue
- 支持Console管理与http远程管理，支持动态配置加载
- 多种模式：web服务器，反向代理，插件
- 支持插件：GIF/PNG互换？
11、MogileFS
LJ使用开源的MogileFS作为分布式文件存储系统。MogileFS使用非常简单，它的主要设计思想是：
- 文件属于类（类是最小的复制单位）
- 跟踪文件存储位置
- 在不同主机上存储
- 使用MySQL集群统一存储分布信息
- 大容易廉价磁盘
到目前为止就这么多了，更多文档可以在http://www.danga.com/words/找到。Danga.com和LiveJournal.com的同学们拿这个文档参加了两次MySQL Con，两次OS Con，以及众多的其它会议，无私的把他们的经验分享出来，值得我们学习。在web2.0时代快速开发得到大家越来越多的重视，但良好的设计仍是每一个应用的基础，希望web2.0们在成长为Top500网站的路上，不要因为架构阻碍了网站的发展。
从这个例子中，我们可以学习到一些设计理念。不仅仅服务器系统架构要搭建好了，相应的程序设计也必须按照系统架构做相应的设计，这个例子采用的是大量的开源软件和MySpace基于不同的系统架构，并采用了Mysql集群和分布式文件存储系统。将系统的性能大大提升，让我们有很大的借鉴意义。
随着互联网的用户激增，每个网站的日访问量都在扩大，由于系统架构初期规划设计不当，将导致大量的架构改造工作，所以初期规划好架构可以为将来节省非常多的工作。
本人提出来的网站架构优化部分，应该因地制宜，根据需要选择不同的优化功能，切忌生搬硬套。
有意进行深入探讨的，可以和我联系，ＱＱ：29011218，ＭＳＮ：onenight11@hotmail.com
在我们探讨网站架构之前，我们先来看两篇文章，希望大家能够从这些文章中总结出些经验。
看了这么长的故事，让我们来总结一下：
现在ArthurXF本人正在搞PHP等技术培训，如果想学习的人可以跟我联系。另外培训的招生简章在这个网址，想了解的可以去看看。加我QQ：29011218交流也可。
PHP培训招生简章
本人提出来的网站架构优化部分，应该因地制宜，根据需要选择不同的优化功能，切忌生搬硬套。
有意进行深入探讨的，可以和我联系，ＱＱ：29011218，ＭＳＮ：onenight11@hotmail.com
在我们探讨网站架构之前，我们先来看两篇文章，希望大家能够从这些文章中总结出些经验。
引用
亿万用户网站MySpace的成功秘密
◎ 文 / David F. Carr 译 / 罗小平
高速增长的访问量给社区网络的技术体系带来了巨大挑战。MySpace的开发者多年来不断重构站点软件、数据库和存储系统，以期与自身的成长同步——目前，该站点月访问量已达400亿。绝大多数网站需要应对的流量都不及MySpace的一小部分，但那些指望迈入庞大在线市场的人，可以从MySpace的成长过程学到知识。
用户的烦恼
Drew，是个来自达拉斯的17岁小伙子，在他的MySpace个人资料页上，可以看到他的袒胸照，看样子是自己够着手拍的。他的好友栏全是漂亮姑娘和靓车的链接，另外还说自己参加了学校田径队，爱好吉他，开一辆蓝色福特野马。
不过在用户反映问题的论坛里，似乎他的火气很大。“赶紧弄好这该死的收件箱！”他大写了所有单词。使用MySpace的用户个人消息系统可以收发信息，但当他要查看一条消息时，页面却出现提示：“非常抱歉……消息错误”。
Drew的抱怨说明1.4亿用户非常重视在线交流系统，这对MySpace来说是个好消息。但也恰是这点让MySpace成了全世界最繁忙的站点之一。
11月，MySpace的美国国内互联网用户访问流量首次超过Yahoo。comScore Media Metrix公司提供的资料显示，MySpace当月访问量为387亿，而Yahoo是380.5亿。
显然，MySpace的成长太快了——从2003年11月正式上线到现在不过三年。这使它很早就要面对只有极少数公司才会遇到的高可扩展性问题的严峻挑战。
事实上，MySpace的Web服务器和数据库经常性超负荷，其用户频繁遭遇“意外错误”和“站点离线维护”等告示。包括Drew在内的MySpace用户经常无法收发消息、更新个人资料或处理其他日常事务，他们不得不在论坛抱怨不停。
尤其是最近，MySpace可能经常性超负荷。因为Keynote Systems公司性能监测服务机构负责人Shawn White说，“难以想象，在有些时候，我们发现20%的错误日志都来自MySpace，有时候甚至达到30%以至40%……而Yahoo、Salesforce.com和其他提供商用服务的站点，从来不会出现这样的数字。”他告诉我们，其他大型站点的日错误率一般就1%多点。
顺便提及，MySpace在2006年7月24号晚上开始了长达12小时的瘫痪，期间只有一个可访问页面——该页面解释说位于洛杉矶的主数据中心发生故障。为了让大家耐心等待服务恢复，该页面提供了用Flash开发的派克人（Pac-Man）游戏。Web站点跟踪服务研究公司总经理Bill Tancer说，尤其有趣的是，MySpace瘫痪期间，访问量不降反升，“这说明了人们对MySpace的痴迷——所有人都拥在它的门口等着放行”。
现Nielsen Norman Group 咨询公司负责人、原Sun Microsystems公司工程师，因在Web站点方面的评论而闻名的Jakob Nielsen说，MySpace的系统构建方法显然与Yahoo、eBay以及Google都不相同。和很多观察家一样，他相信MySpace对其成长速度始料未及。“虽然我不认为他们必须在计算机科学领域全面创新，但他们面对的的确是一个巨大的科学难题。”他说。
MySpace开发人员已经多次重构站点软件、数据库和存储系统，以满足爆炸性的成长需要，但此工作永不会停息。“就像粉刷金门大桥，工作完成之时，就是重新来过之日。”（译者注：意指工人从桥头开始粉刷，当到达桥尾时，桥头涂料已经剥落，必须重新开始）MySpace技术副总裁Jim Benedetto说。
既然如此，MySpace的技术还有何可学之处？因为MySpace事实上已经解决了很多系统扩展性问题，才能走到今天。
Benedetto说他的项目组有很多教训必须总结，他们仍在学习，路漫漫而修远。他们当前需要改进的工作包括实现更灵活的数据缓存系统，以及为避免再次出现类似7月瘫痪事件的地理上分布式架构。
背景知识
MySpace目前的努力方向是解决扩展性问题，但其领导人最初关注的是系统性能。
3年多前，一家叫做Intermix Media（早先叫eUniverse。这家公司从事各类电子邮件营销和网上商务）的公司推出了MySpace。而其创建人是Chris DeWolfe和Tom Anderson，他们原来也有一家叫做ResponseBase的电子邮件营销公司，后于2002年出售给Intermix。据Brad Greenspan（Intermix前CEO）运作的一个网站披露，ResponseBase团队为此获得2百万美金外加分红。Intermix是一家颇具侵略性的互联网商务公司——部分做法可能有点过头。2005年，纽约总检察长Eliot Spitzer——现在是纽约州长——起诉Intermix使用恶意广告软件推广业务，Intermix最后以790万美元的代价达成和解。
2003年，美国国会通过《反垃圾邮件法》（CAN-SPAM Act），意在控制滥发邮件的营销行为。Intermix领导人DeWolfe和Anderson意识到新法案将严重打击公司的电子邮件营销业务，“因此必须寻找新的方向。”受聘于Intermix负责重写公司邮件营销软件的Duc Chau说。
当时有个叫Friendster的交友网站，Anderson和DeWolfe很早就是它的会员。于是他们决定创建自己的网上社区。他们去除了Friendster在用户自我表述方面的诸多限制，并重点突出音乐（尤其是重金属乐），希望以此吸引用户。Chau使用Perl开发了最初的MySpace版本，运行于Apache Web服务器，后台使用MySQL数据库。但它没有通过终审，因为Intermix的多数开发人员对ColdFusion（一个Web应用程序环境，最初由Allaire开发，现为Adobe所有）更为熟悉。因此，最后发布的产品采用ColdFusion开发，运行在Windows上，并使用MS SQL Server作为数据库服务器。
Chau就在那时离开了公司，将开发工作交给其他人，包括Aber Whitcomb（Intermix的技术专家，现在是MySpace技术总监）和Benedetto（MySpace现技术副总裁，大概于MySpace上线一个月后加入）。
MySpace上线的2003年，恰恰是Friendster在满足日益增长的用户需求问题上遭遇麻烦的时期。在财富杂志最近的一次采访中，Friendster总裁Kent Lindstrom承认他们的服务出现问题选错了时候。那时，Friendster传输一个页面需要20到30秒，而MySpace只需2到3秒。
结果，Friendster用户开始转投MySpace，他们认为后者更为可靠。
今天，MySpace无疑已是社区网站之王。社区网站是指那些帮助用户彼此保持联系、通过介绍或搜索、基于共同爱好或教育经历交友的Web站点。在这个领域比较有名的还有最初面向大学生的Facebook、侧重职业交流的LinkedIn，当然还少不了Friendster。MySpace宣称自己是“下一代门户”，强调内容的丰富多彩（如音乐、趣事和视频等）。其运作方式颇似一个虚拟的夜总会——为未成年人在边上安排一个果汁吧，而显著位置则是以性为目的的约会，和寻找刺激派对气氛的年轻人的搜索服务。
用户注册时，需要提供个人基本信息，主要包括籍贯、性取向和婚姻状况。虽然MySpace屡遭批评，指其为网上性犯罪提供了温床，但对于未成年人，有些功能还是不予提供的。
MySpace的个人资料页上表述自己的方式很多，如文本式“关于本人”栏、选择加载入MySpace音乐播放器的歌曲，以及视频、交友要求等。它还允许用户使用CSS（一种Web标准格式语言，用户以此可设置页面元素的字体、颜色和页面背景图像）自由设计个人页面，这也提升了人气。不过结果是五花八门——很多用户的页面布局粗野、颜色迷乱，进去后找不到东南西北，不忍卒读；而有些人则使用了专业设计的模版（可阅读《Too Much of a Good Thing?》第49页），页面效果很好。
在网站上线8个月后，开始有大量用户邀请朋友注册MySpace，因此用户量大增。“这就是网络的力量，这种趋势一直没有停止。”Chau说。
拥有Fox电视网络和20th Century Fox影业公司的媒体帝国——新闻集团，看到了他们在互联网用户中的机会，于是在2005年斥资5.8亿美元收购了MySpace。新闻集团董事局主席Rupert Murdoch最近向一个投资团透露，他认为MySpace目前是世界主要Web门户之一，如果现在出售MySpace，那么可获60亿美元——这比2005年收购价格的10倍还多！新闻集团还惊人地宣称，MySpace在2006年7月结束的财政年度里总收入约2亿美元，而且预期在2007年度，Fox Interactive公司总收入将达到5亿美元，其中4亿来自MySpace。
然而MySpace还在继续成长。12月份，它的注册账户达到1.4亿，而2005年11月时不过4千万。当然，这个数字并不等于真实的用户个体数，因为有些人可能有多个帐号，而且个人资料也表明有些是乐队，或者是虚构的名字，如波拉特（译者注：喜剧电影《Borat》主角），还有像Burger King（译者注：美国最大的汉堡连锁集团）这样的品牌名。
当然，这么多的用户不停发布消息、撰写评论或者更新个人资料，甚至一些人整天都泡在Space上，必然给MySpace的技术工作带来前所未有的挑战。而传统新闻站点的绝大多数内容都是由编辑团队整理后主动提供给用户消费，它们的内容数据库通常可以优化为只读模式，因为用户评论等引起的增加和更新操作很少。而MySpace是由用户提供内容，数据库很大比例的操作都是插入和更新，而非读取。
浏览MySpace上的任何个人资料时，系统都必须先查询数据库，然后动态创建页面。当然，通过数据缓存，可以减轻数据库的压力，但这种方案必须解决原始数据被用户频繁更新带来的同步问题。
MySpace的站点架构已经历了5个版本——每次都是用户数达到一个里程碑后，必须做大量的调整和优化。Benedetto说，“但我们始终跟不上形势的发展速度。我们重构重构再重构，一步步挪到今天”。
尽管MySpace拒绝了正式采访，但Benedetto在参加11月于拉斯维加斯召开的SQL Server Connections会议时还是回答了Baseline的问题。本文的不少技术信息还来源于另一次重要会议——Benedetto和他的老板——技术总监Whitcomb今年3月出席的Microsoft MIX Web开发者大会。
据他们讲，MySpace很多大的架构变动都发生在2004和2005年早期——用户数在当时从几十万迅速攀升到了几百万。
在每个里程碑，站点负担都会超过底层系统部分组件的最大载荷，特别是数据库和存储系统。接着，功能出现问题，用户失声尖叫。最后，技术团队必须为此修订系统策略。
虽然自2005年早期，站点账户数超过7百万后，系统架构到目前为止保持了相对稳定，但MySpace仍然在为SQL Server支持的同时连接数等方面继续攻坚，Benedetto说，“我们已经尽可能把事情做到最好”。
里程碑一：50万账户
按Benedetto 的说法，MySpace最初的系统很小，只有两台Web服务器和一个数据库服务器。那时使用的是Dell双CPU、4G内存的系统。
单个数据库就意味着所有数据都存储在一个地方，再由两台Web服务器分担处理用户请求的工作量。但就像MySpace后来的几次底层系统修订时的情况一样，三服务器架构很快不堪重负。此后一个时期内，MySpace基本是通过添置更多Web服务器来对付用户暴增问题的。
但到在2004年早期，MySpace用户数增长到50万后，数据库服务器也已开始汗流浃背。
但和Web服务器不同，增加数据库可没那么简单。如果一个站点由多个数据库支持，设计者必须考虑的是，如何在保证数据一致性的前提下，让多个数据库分担压力。
在第二代架构中，MySpace运行在3个SQL Server数据库服务器上——一个为主，所有的新数据都向它提交，然后由它复制到其他两个；另两个全力向用户供给数据，用以在博客和个人资料栏显示。这种方式在一段时间内效果很好——只要增加数据库服务器，加大硬盘，就可以应对用户数和访问量的增加。
里程碑二：1-2百万账户
MySpace注册数到达1百万至2百万区间后，数据库服务器开始受制于I/O容量——即它们存取数据的速度。而当时才是2004年中，距离上次数据库系统调整不过数月。用户的提交请求被阻塞，就像千人乐迷要挤进只能容纳几百人的夜总会，站点开始遭遇“主要矛盾”，Benedetto说，这意味着MySpace永远都会轻度落后于用户需求。
“有人花5分钟都无法完成留言，因此用户总是抱怨说网站已经完蛋了。”他补充道。
这一次的数据库架构按照垂直分割模式设计，不同的数据库服务于站点的不同功能，如登录、用户资料和博客。于是，站点的扩展性问题看似又可以告一段落了，可以歇一阵子。
垂直分割策略利于多个数据库分担访问压力，当用户要求增加新功能时，MySpace将投入新的数据库予以支持它。账户到达2百万后，MySpace还从存储设备与数据库服务器直接交互的方式切换到SAN（Storage Area Network，存储区域网络）——用高带宽、专门设计的网络将大量磁盘存储设备连接在一起，而数据库连接到SAN。这项措施极大提升了系统性能、正常运行时间和可靠性，Benedetto说。
里程碑三：3百万账户
当用户继续增加到3百万后，垂直分割策略也开始难以为继。尽管站点的各个应用被设计得高度独立，但有些信息必须共享。在这个架构里，每个数据库必须有各自的用户表副本——MySpace授权用户的电子花名册。这就意味着一个用户注册时，该条账户记录必须在9个不同数据库上分别创建。但在个别情况下，如果其中某台数据库服务器临时不可到达，对应事务就会失败，从而造成账户非完全创建，最终导致此用户的该项服务无效。
另外一个问题是，个别应用如博客增长太快，那么专门为它服务的数据库就有巨大压力。
2004年中，MySpace面临Web开发者称之为“向上扩展”对“向外扩展”（译者注：Scale Up和Scale Out，也称硬件扩展和软件扩展）的抉择——要么扩展到更大更强、也更昂贵的服务器上，要么部署大量相对便宜的服务器来分担数据库压力。一般来说，大型站点倾向于向外扩展，因为这将让它们得以保留通过增加服务器以提升系统能力的后路。
但成功地向外扩展架构必须解决复杂的分布式计算问题，大型站点如Google、Yahoo和Amazon.com，都必须自行研发大量相关技术。以Google为例，它构建了自己的分布式文件系统。
另外，向外扩展策略还需要大量重写原来软件，以保证系统能在分布式服务器上运行。“搞不好，开发人员的所有工作都将白费”，Benedetto说。
因此，MySpace首先将重点放在了向上扩展上，花费了大约1个半月时间研究升级到32CPU服务器以管理更大数据库的问题。Benedetto说，“那时候，这个方案看似可能解决一切问题。”如稳定性，更棒的是对现有软件几乎没有改动要求。
糟糕的是，高端服务器极其昂贵，是购置同样处理能力和内存速度的多台服务器总和的很多倍。而且，站点架构师预测，从长期来看，即便是巨型数据库，最后也会不堪重负，Benedetto说，“换句话讲，只要增长趋势存在，我们最后无论如何都要走上向外扩展的道路。”
因此，MySpace最终将目光移到分布式计算架构——它在物理上分布的众多服务器，整体必须逻辑上等同于单台机器。拿数据库来说，就不能再像过去那样将应用拆分，再以不同数据库分别支持，而必须将整个站点看作一个应用。现在，数据库模型里只有一个用户表，支持博客、个人资料和其他核心功能的数据都存储在相同数据库。
既然所有的核心数据逻辑上都组织到一个数据库，那么MySpace必须找到新的办法以分担负荷——显然，运行在普通硬件上的单个数据库服务器是无能为力的。这次，不再按站点功能和应用分割数据库，MySpace开始将它的用户按每百万一组分割，然后将各组的全部数据分别存入独立的SQL Server实例。目前，MySpace的每台数据库服务器实际运行两个SQL Server实例，也就是说每台服务器服务大约2百万用户。Benedetto指出，以后还可以按照这种模式以更小粒度划分架构，从而优化负荷分担。
当然，还是有一个特殊数据库保存了所有账户的名称和密码。用户登录后，保存了他们其他数据的数据库再接管服务。特殊数据库的用户表虽然庞大，但它只负责用户登录，功能单一，所以负荷还是比较容易控制的。
里程碑四：9百万到1千7百万账户
2005年早期，账户达到9百万后，MySpace开始用Microsoft的C#编写ASP.NET程序。C#是C语言的最新派生语言，吸收了C++和Java的优点，依托于Microsoft .NET框架（Microsoft为软件组件化和分布式计算而设计的模型架构）。ASP.NET则由编写Web站点脚本的ASP技术演化而来，是Microsoft目前主推的Web站点编程环境。
可以说是立竿见影，MySpace马上就发现ASP.NET程序运行更有效率，与ColdFusion相比，完成同样任务需消耗的处理器能力更小。据技术总监Whitcomb说，新代码需要150台服务器完成的工作，如果用ColdFusion则需要246台。Benedetto还指出，性能上升的另一个原因可能是在变换软件平台，并用新语言重写代码的过程中，程序员复审并优化了一些功能流程。
最终，MySpace开始大规模迁移到ASP.NET。即便剩余的少部分ColdFusion代码，也从Cold-Fusion服务器搬到了ASP.NET，因为他们得到了BlueDragon.NET（乔治亚州阿尔法利塔New Atlanta Communications公司的产品，它能将ColdFusion代码自动重新编译到Microsoft平台）的帮助。
账户达到1千万时，MySpace再次遭遇存储瓶颈问题。SAN的引入解决了早期一些性能问题，但站点目前的要求已经开始周期性超越SAN的I/O容量——即它从磁盘存储系统读写数据的极限速度。
原因之一是每数据库1百万账户的分割策略，通常情况下的确可以将压力均分到各台服务器，但现实并非一成不变。比如第七台账户数据库上线后，仅仅7天就被塞满了，主要原因是佛罗里达一个乐队的歌迷疯狂注册。
某个数据库可能因为任何原因，在任何时候遭遇主要负荷，这时，SAN中绑定到该数据库的磁盘存储设备簇就可能过载。“SAN让磁盘I/O能力大幅提升了，但将它们绑定到特定数据库的做法是错误的。”Benedetto说。
最初，MySpace通过定期重新分配SAN中数据，以让其更为均衡的方法基本解决了这个问题，但这是一个人工过程，“大概需要两个人全职工作。”Benedetto说。
长期解决方案是迁移到虚拟存储体系上，这样，整个SAN被当作一个巨型存储池，不再要求每个磁盘为特定应用服务。MySpace目前采用了一种新型SAN设备——来自加利福尼亚州弗里蒙特的3PARdata。
在3PAR的系统里，仍能在逻辑上按容量划分数据存储，但它不再被绑定到特定磁盘或磁盘簇，而是散布于大量磁盘。这就使均分数据访问负荷成为可能。当数据库需要写入一组数据时，任何空闲磁盘都可以马上完成这项工作，而不再像以前那样阻塞在可能已经过载的磁盘阵列处。而且，因为多个磁盘都有数据副本，读取数据时，也不会使SAN的任何组件过载。
当2005年春天账户数达到1千7百万时，MySpace又启用了新的策略以减轻存储系统压力，即增加数据缓存层——位于Web服务器和数据库服务器之间，其唯一职能是在内存中建立被频繁请求数据对象的副本，如此一来，不访问数据库也可以向Web应用供给数据。换句话说，100个用户请求同一份资料，以前需要查询数据库100次，而现在只需1次，其余都可从缓存数据中获得。当然如果页面变化，缓存的数据必须从内存擦除，然后重新从数据库获取——但在此之前，数据库的压力已经大大减轻，整个站点的性能得到提升。
缓存区还为那些不需要记入数据库的数据提供了驿站，比如为跟踪用户会话而创建的临时文件——Benedetto坦言他需要在这方面补课，“我是数据库存储狂热分子，因此我总是想着将万事万物都存到数据库。”但将像会话跟踪这类的数据也存到数据库，站点将陷入泥沼。
增加缓存服务器是“一开始就应该做的事情，但我们成长太快，以致于没有时间坐下来好好研究这件事情。”Benedetto补充道。
里程碑五：2千6百万账户
2005年中期，服务账户数达到2千6百万时，MySpace切换到了还处于beta测试的SQL Server 2005。转换何太急？主流看法是2005版支持64位处理器。但Benedetto说，“这不是主要原因，尽管这也很重要；主要还是因为我们对内存的渴求。”支持64位的数据库可以管理更多内存。
更多内存就意味着更高的性能和更大的容量。原来运行32位版本的SQL Server服务器，能同时使用的内存最多只有4G。切换到64位，就好像加粗了输水管的直径。升级到SQL Server 2005和64位Windows Server 2003后，MySpace每台服务器配备了32G内存，后于2006年再次将配置标准提升到64G。
意外错误
如果没有对系统架构的历次修改与升级，MySpace根本不可能走到今天。但是，为什么系统还经常吃撑着了？很多用户抱怨的“意外错误”是怎么引起的呢？
原因之一是MySpace对Microsoft的Web技术的应用已经进入连Microsoft自己也才刚刚开始探索的领域。比如11月，超出SQL Server最大同时连接数，MySpace系统崩溃。Benedetto说，这类可能引发系统崩溃的情况大概三天才会出现一次，但仍然过于频繁了，以致惹人恼怒。一旦数据库罢工，“无论这种情况什么时候发生，未缓存的数据都不能从SQL Server获得，那么你就必然看到一个‘意外错误’提示。”他解释说。
去年夏天，MySpace的Windows 2003多次自动停止服务。后来发现是操作系统一个内置功能惹的祸——预防分布式拒绝服务攻击（黑客使用很多客户机向服务器发起大量连接请求，以致服务器瘫痪）。MySpace和其他很多顶级大站点一样，肯定会经常遭受攻击，但它应该从网络级而不是依靠Windows本身的功能来解决问题——否则，大量MySpace合法用户连接时也会引起服务器反击。
“我们花了大约一个月时间寻找Windows 2003服务器自动停止的原因。”Benedetto说。最后，通过Microsoft的帮助，他们才知道该怎么通知服务器：“别开枪，是友军。”
紧接着是在去年7月某个周日晚上，MySpace总部所在地洛杉矶停电，造成整个系统停运12小时。大型Web站点通常要在地理上分布配置多个数据中心以预防单点故障。本来，MySpace还有其他两个数据中心以应对突发事件，但Web服务器都依赖于部署在洛杉矶的SAN。没有洛杉矶的SAN，Web服务器除了恳求你耐心等待，不能提供任何服务。
Benedetto说，主数据中心的可靠性通过下列措施保证：可接入两张不同电网，另有后备电源和一台储备有30天燃料的发电机。但在这次事故中，不仅两张电网失效，而且在切换到备份电源的过程中，操作员烧掉了主动力线路。
2007年中，MySpace在另两个后备站点上也建设了SAN。这对分担负荷大有帮助——正常情况下，每个SAN都能负担三分之一的数据访问量。而在紧急情况下，任何一个站点都可以独立支撑整个服务，Benedetto说。
MySpace仍然在为提高稳定性奋斗，虽然很多用户表示了足够信任且能原谅偶现的错误页面。
“作为开发人员，我憎恶Bug，它太气人了。”Dan Tanner这个31岁的德克萨斯软件工程师说，他通过MySpace重新联系到了高中和大学同学。“不过，MySpace对我们的用处很大，因此我们可以原谅偶发的故障和错误。” Tanner说，如果站点某天出现故障甚至崩溃，恢复以后他还是会继续使用。
这就是为什么Drew在论坛里咆哮时，大部分用户都告诉他应该保持平静，如果等几分钟，问题就会解决的原因。Drew无法平静，他写道，“我已经两次给MySpace发邮件，而它说一小时前还是正常的，现在出了点问题……完全是一堆废话。”另一个用户回复说，“毕竟它是免费的。”Benedetto坦承100%的可靠性不是他的目标。“它不是银行，而是一个免费的服务。”他说。
换句话说，MySpace的偶发故障可能造成某人最后更新的个人资料丢失，但并不意味着网站弄丢了用户的钱财。“关键是要认识到，与保证站点性能相比，丢失少许数据的故障是可接受的。”Benedetto说。所以，MySpace甘冒丢失2分钟到2小时内任意点数据的危险，在SQL Server配置里延长了“checkpoint”操作——它将待更新数据永久记录到磁盘——的间隔时间，因为这样做可以加快数据库的运行。
Benedetto说，同样，开发人员还经常在几个小时内就完成构思、编码、测试和发布全过程。这有引入Bug的风险，但这样做可以更快实现新功能。而且，因为进行大规模真实测试不具可行性，他们的测试通常是在仅以部分活跃用户为对象，且用户对软件新功能和改进不知就里的情况下进行的。因为事实上不可能做真实的加载测试，他们做的测试通常都是针对站点。
“我们犯过大量错误，”Benedetto说，“但到头来，我认为我们做对的还是比做错的多。”
◎ 文 / David F. Carr 译 / 罗小平
高速增长的访问量给社区网络的技术体系带来了巨大挑战。MySpace的开发者多年来不断重构站点软件、数据库和存储系统，以期与自身的成长同步——目前，该站点月访问量已达400亿。绝大多数网站需要应对的流量都不及MySpace的一小部分，但那些指望迈入庞大在线市场的人，可以从MySpace的成长过程学到知识。
用户的烦恼
Drew，是个来自达拉斯的17岁小伙子，在他的MySpace个人资料页上，可以看到他的袒胸照，看样子是自己够着手拍的。他的好友栏全是漂亮姑娘和靓车的链接，另外还说自己参加了学校田径队，爱好吉他，开一辆蓝色福特野马。
不过在用户反映问题的论坛里，似乎他的火气很大。“赶紧弄好这该死的收件箱！”他大写了所有单词。使用MySpace的用户个人消息系统可以收发信息，但当他要查看一条消息时，页面却出现提示：“非常抱歉……消息错误”。
Drew的抱怨说明1.4亿用户非常重视在线交流系统，这对MySpace来说是个好消息。但也恰是这点让MySpace成了全世界最繁忙的站点之一。
11月，MySpace的美国国内互联网用户访问流量首次超过Yahoo。comScore Media Metrix公司提供的资料显示，MySpace当月访问量为387亿，而Yahoo是380.5亿。
显然，MySpace的成长太快了——从2003年11月正式上线到现在不过三年。这使它很早就要面对只有极少数公司才会遇到的高可扩展性问题的严峻挑战。
事实上，MySpace的Web服务器和数据库经常性超负荷，其用户频繁遭遇“意外错误”和“站点离线维护”等告示。包括Drew在内的MySpace用户经常无法收发消息、更新个人资料或处理其他日常事务，他们不得不在论坛抱怨不停。
尤其是最近，MySpace可能经常性超负荷。因为Keynote Systems公司性能监测服务机构负责人Shawn White说，“难以想象，在有些时候，我们发现20%的错误日志都来自MySpace，有时候甚至达到30%以至40%……而Yahoo、Salesforce.com和其他提供商用服务的站点，从来不会出现这样的数字。”他告诉我们，其他大型站点的日错误率一般就1%多点。
顺便提及，MySpace在2006年7月24号晚上开始了长达12小时的瘫痪，期间只有一个可访问页面——该页面解释说位于洛杉矶的主数据中心发生故障。为了让大家耐心等待服务恢复，该页面提供了用Flash开发的派克人（Pac-Man）游戏。Web站点跟踪服务研究公司总经理Bill Tancer说，尤其有趣的是，MySpace瘫痪期间，访问量不降反升，“这说明了人们对MySpace的痴迷——所有人都拥在它的门口等着放行”。
现Nielsen Norman Group 咨询公司负责人、原Sun Microsystems公司工程师，因在Web站点方面的评论而闻名的Jakob Nielsen说，MySpace的系统构建方法显然与Yahoo、eBay以及Google都不相同。和很多观察家一样，他相信MySpace对其成长速度始料未及。“虽然我不认为他们必须在计算机科学领域全面创新，但他们面对的的确是一个巨大的科学难题。”他说。
MySpace开发人员已经多次重构站点软件、数据库和存储系统，以满足爆炸性的成长需要，但此工作永不会停息。“就像粉刷金门大桥，工作完成之时，就是重新来过之日。”（译者注：意指工人从桥头开始粉刷，当到达桥尾时，桥头涂料已经剥落，必须重新开始）MySpace技术副总裁Jim Benedetto说。
既然如此，MySpace的技术还有何可学之处？因为MySpace事实上已经解决了很多系统扩展性问题，才能走到今天。
Benedetto说他的项目组有很多教训必须总结，他们仍在学习，路漫漫而修远。他们当前需要改进的工作包括实现更灵活的数据缓存系统，以及为避免再次出现类似7月瘫痪事件的地理上分布式架构。
背景知识
MySpace目前的努力方向是解决扩展性问题，但其领导人最初关注的是系统性能。
3年多前，一家叫做Intermix Media（早先叫eUniverse。这家公司从事各类电子邮件营销和网上商务）的公司推出了MySpace。而其创建人是Chris DeWolfe和Tom Anderson，他们原来也有一家叫做ResponseBase的电子邮件营销公司，后于2002年出售给Intermix。据Brad Greenspan（Intermix前CEO）运作的一个网站披露，ResponseBase团队为此获得2百万美金外加分红。Intermix是一家颇具侵略性的互联网商务公司——部分做法可能有点过头。2005年，纽约总检察长Eliot Spitzer——现在是纽约州长——起诉Intermix使用恶意广告软件推广业务，Intermix最后以790万美元的代价达成和解。
2003年，美国国会通过《反垃圾邮件法》（CAN-SPAM Act），意在控制滥发邮件的营销行为。Intermix领导人DeWolfe和Anderson意识到新法案将严重打击公司的电子邮件营销业务，“因此必须寻找新的方向。”受聘于Intermix负责重写公司邮件营销软件的Duc Chau说。
当时有个叫Friendster的交友网站，Anderson和DeWolfe很早就是它的会员。于是他们决定创建自己的网上社区。他们去除了Friendster在用户自我表述方面的诸多限制，并重点突出音乐（尤其是重金属乐），希望以此吸引用户。Chau使用Perl开发了最初的MySpace版本，运行于Apache Web服务器，后台使用MySQL数据库。但它没有通过终审，因为Intermix的多数开发人员对ColdFusion（一个Web应用程序环境，最初由Allaire开发，现为Adobe所有）更为熟悉。因此，最后发布的产品采用ColdFusion开发，运行在Windows上，并使用MS SQL Server作为数据库服务器。
Chau就在那时离开了公司，将开发工作交给其他人，包括Aber Whitcomb（Intermix的技术专家，现在是MySpace技术总监）和Benedetto（MySpace现技术副总裁，大概于MySpace上线一个月后加入）。
MySpace上线的2003年，恰恰是Friendster在满足日益增长的用户需求问题上遭遇麻烦的时期。在财富杂志最近的一次采访中，Friendster总裁Kent Lindstrom承认他们的服务出现问题选错了时候。那时，Friendster传输一个页面需要20到30秒，而MySpace只需2到3秒。
结果，Friendster用户开始转投MySpace，他们认为后者更为可靠。
今天，MySpace无疑已是社区网站之王。社区网站是指那些帮助用户彼此保持联系、通过介绍或搜索、基于共同爱好或教育经历交友的Web站点。在这个领域比较有名的还有最初面向大学生的Facebook、侧重职业交流的LinkedIn，当然还少不了Friendster。MySpace宣称自己是“下一代门户”，强调内容的丰富多彩（如音乐、趣事和视频等）。其运作方式颇似一个虚拟的夜总会——为未成年人在边上安排一个果汁吧，而显著位置则是以性为目的的约会，和寻找刺激派对气氛的年轻人的搜索服务。
用户注册时，需要提供个人基本信息，主要包括籍贯、性取向和婚姻状况。虽然MySpace屡遭批评，指其为网上性犯罪提供了温床，但对于未成年人，有些功能还是不予提供的。
MySpace的个人资料页上表述自己的方式很多，如文本式“关于本人”栏、选择加载入MySpace音乐播放器的歌曲，以及视频、交友要求等。它还允许用户使用CSS（一种Web标准格式语言，用户以此可设置页面元素的字体、颜色和页面背景图像）自由设计个人页面，这也提升了人气。不过结果是五花八门——很多用户的页面布局粗野、颜色迷乱，进去后找不到东南西北，不忍卒读；而有些人则使用了专业设计的模版（可阅读《Too Much of a Good Thing?》第49页），页面效果很好。
在网站上线8个月后，开始有大量用户邀请朋友注册MySpace，因此用户量大增。“这就是网络的力量，这种趋势一直没有停止。”Chau说。
拥有Fox电视网络和20th Century Fox影业公司的媒体帝国——新闻集团，看到了他们在互联网用户中的机会，于是在2005年斥资5.8亿美元收购了MySpace。新闻集团董事局主席Rupert Murdoch最近向一个投资团透露，他认为MySpace目前是世界主要Web门户之一，如果现在出售MySpace，那么可获60亿美元——这比2005年收购价格的10倍还多！新闻集团还惊人地宣称，MySpace在2006年7月结束的财政年度里总收入约2亿美元，而且预期在2007年度，Fox Interactive公司总收入将达到5亿美元，其中4亿来自MySpace。
然而MySpace还在继续成长。12月份，它的注册账户达到1.4亿，而2005年11月时不过4千万。当然，这个数字并不等于真实的用户个体数，因为有些人可能有多个帐号，而且个人资料也表明有些是乐队，或者是虚构的名字，如波拉特（译者注：喜剧电影《Borat》主角），还有像Burger King（译者注：美国最大的汉堡连锁集团）这样的品牌名。
当然，这么多的用户不停发布消息、撰写评论或者更新个人资料，甚至一些人整天都泡在Space上，必然给MySpace的技术工作带来前所未有的挑战。而传统新闻站点的绝大多数内容都是由编辑团队整理后主动提供给用户消费，它们的内容数据库通常可以优化为只读模式，因为用户评论等引起的增加和更新操作很少。而MySpace是由用户提供内容，数据库很大比例的操作都是插入和更新，而非读取。
浏览MySpace上的任何个人资料时，系统都必须先查询数据库，然后动态创建页面。当然，通过数据缓存，可以减轻数据库的压力，但这种方案必须解决原始数据被用户频繁更新带来的同步问题。
MySpace的站点架构已经历了5个版本——每次都是用户数达到一个里程碑后，必须做大量的调整和优化。Benedetto说，“但我们始终跟不上形势的发展速度。我们重构重构再重构，一步步挪到今天”。
尽管MySpace拒绝了正式采访，但Benedetto在参加11月于拉斯维加斯召开的SQL Server Connections会议时还是回答了Baseline的问题。本文的不少技术信息还来源于另一次重要会议——Benedetto和他的老板——技术总监Whitcomb今年3月出席的Microsoft MIX Web开发者大会。
据他们讲，MySpace很多大的架构变动都发生在2004和2005年早期——用户数在当时从几十万迅速攀升到了几百万。
在每个里程碑，站点负担都会超过底层系统部分组件的最大载荷，特别是数据库和存储系统。接着，功能出现问题，用户失声尖叫。最后，技术团队必须为此修订系统策略。
虽然自2005年早期，站点账户数超过7百万后，系统架构到目前为止保持了相对稳定，但MySpace仍然在为SQL Server支持的同时连接数等方面继续攻坚，Benedetto说，“我们已经尽可能把事情做到最好”。
里程碑一：50万账户
按Benedetto 的说法，MySpace最初的系统很小，只有两台Web服务器和一个数据库服务器。那时使用的是Dell双CPU、4G内存的系统。
单个数据库就意味着所有数据都存储在一个地方，再由两台Web服务器分担处理用户请求的工作量。但就像MySpace后来的几次底层系统修订时的情况一样，三服务器架构很快不堪重负。此后一个时期内，MySpace基本是通过添置更多Web服务器来对付用户暴增问题的。
但到在2004年早期，MySpace用户数增长到50万后，数据库服务器也已开始汗流浃背。
但和Web服务器不同，增加数据库可没那么简单。如果一个站点由多个数据库支持，设计者必须考虑的是，如何在保证数据一致性的前提下，让多个数据库分担压力。
在第二代架构中，MySpace运行在3个SQL Server数据库服务器上——一个为主，所有的新数据都向它提交，然后由它复制到其他两个；另两个全力向用户供给数据，用以在博客和个人资料栏显示。这种方式在一段时间内效果很好——只要增加数据库服务器，加大硬盘，就可以应对用户数和访问量的增加。
里程碑二：1-2百万账户
MySpace注册数到达1百万至2百万区间后，数据库服务器开始受制于I/O容量——即它们存取数据的速度。而当时才是2004年中，距离上次数据库系统调整不过数月。用户的提交请求被阻塞，就像千人乐迷要挤进只能容纳几百人的夜总会，站点开始遭遇“主要矛盾”，Benedetto说，这意味着MySpace永远都会轻度落后于用户需求。
“有人花5分钟都无法完成留言，因此用户总是抱怨说网站已经完蛋了。”他补充道。
这一次的数据库架构按照垂直分割模式设计，不同的数据库服务于站点的不同功能，如登录、用户资料和博客。于是，站点的扩展性问题看似又可以告一段落了，可以歇一阵子。
垂直分割策略利于多个数据库分担访问压力，当用户要求增加新功能时，MySpace将投入新的数据库予以支持它。账户到达2百万后，MySpace还从存储设备与数据库服务器直接交互的方式切换到SAN（Storage Area Network，存储区域网络）——用高带宽、专门设计的网络将大量磁盘存储设备连接在一起，而数据库连接到SAN。这项措施极大提升了系统性能、正常运行时间和可靠性，Benedetto说。
里程碑三：3百万账户
当用户继续增加到3百万后，垂直分割策略也开始难以为继。尽管站点的各个应用被设计得高度独立，但有些信息必须共享。在这个架构里，每个数据库必须有各自的用户表副本——MySpace授权用户的电子花名册。这就意味着一个用户注册时，该条账户记录必须在9个不同数据库上分别创建。但在个别情况下，如果其中某台数据库服务器临时不可到达，对应事务就会失败，从而造成账户非完全创建，最终导致此用户的该项服务无效。
另外一个问题是，个别应用如博客增长太快，那么专门为它服务的数据库就有巨大压力。
2004年中，MySpace面临Web开发者称之为“向上扩展”对“向外扩展”（译者注：Scale Up和Scale Out，也称硬件扩展和软件扩展）的抉择——要么扩展到更大更强、也更昂贵的服务器上，要么部署大量相对便宜的服务器来分担数据库压力。一般来说，大型站点倾向于向外扩展，因为这将让它们得以保留通过增加服务器以提升系统能力的后路。
但成功地向外扩展架构必须解决复杂的分布式计算问题，大型站点如Google、Yahoo和Amazon.com，都必须自行研发大量相关技术。以Google为例，它构建了自己的分布式文件系统。
另外，向外扩展策略还需要大量重写原来软件，以保证系统能在分布式服务器上运行。“搞不好，开发人员的所有工作都将白费”，Benedetto说。
因此，MySpace首先将重点放在了向上扩展上，花费了大约1个半月时间研究升级到32CPU服务器以管理更大数据库的问题。Benedetto说，“那时候，这个方案看似可能解决一切问题。”如稳定性，更棒的是对现有软件几乎没有改动要求。
糟糕的是，高端服务器极其昂贵，是购置同样处理能力和内存速度的多台服务器总和的很多倍。而且，站点架构师预测，从长期来看，即便是巨型数据库，最后也会不堪重负，Benedetto说，“换句话讲，只要增长趋势存在，我们最后无论如何都要走上向外扩展的道路。”
因此，MySpace最终将目光移到分布式计算架构——它在物理上分布的众多服务器，整体必须逻辑上等同于单台机器。拿数据库来说，就不能再像过去那样将应用拆分，再以不同数据库分别支持，而必须将整个站点看作一个应用。现在，数据库模型里只有一个用户表，支持博客、个人资料和其他核心功能的数据都存储在相同数据库。
既然所有的核心数据逻辑上都组织到一个数据库，那么MySpace必须找到新的办法以分担负荷——显然，运行在普通硬件上的单个数据库服务器是无能为力的。这次，不再按站点功能和应用分割数据库，MySpace开始将它的用户按每百万一组分割，然后将各组的全部数据分别存入独立的SQL Server实例。目前，MySpace的每台数据库服务器实际运行两个SQL Server实例，也就是说每台服务器服务大约2百万用户。Benedetto指出，以后还可以按照这种模式以更小粒度划分架构，从而优化负荷分担。
当然，还是有一个特殊数据库保存了所有账户的名称和密码。用户登录后，保存了他们其他数据的数据库再接管服务。特殊数据库的用户表虽然庞大，但它只负责用户登录，功能单一，所以负荷还是比较容易控制的。
里程碑四：9百万到1千7百万账户
2005年早期，账户达到9百万后，MySpace开始用Microsoft的C#编写ASP.NET程序。C#是C语言的最新派生语言，吸收了C++和Java的优点，依托于Microsoft .NET框架（Microsoft为软件组件化和分布式计算而设计的模型架构）。ASP.NET则由编写Web站点脚本的ASP技术演化而来，是Microsoft目前主推的Web站点编程环境。
可以说是立竿见影，MySpace马上就发现ASP.NET程序运行更有效率，与ColdFusion相比，完成同样任务需消耗的处理器能力更小。据技术总监Whitcomb说，新代码需要150台服务器完成的工作，如果用ColdFusion则需要246台。Benedetto还指出，性能上升的另一个原因可能是在变换软件平台，并用新语言重写代码的过程中，程序员复审并优化了一些功能流程。
最终，MySpace开始大规模迁移到ASP.NET。即便剩余的少部分ColdFusion代码，也从Cold-Fusion服务器搬到了ASP.NET，因为他们得到了BlueDragon.NET（乔治亚州阿尔法利塔New Atlanta Communications公司的产品，它能将ColdFusion代码自动重新编译到Microsoft平台）的帮助。
账户达到1千万时，MySpace再次遭遇存储瓶颈问题。SAN的引入解决了早期一些性能问题，但站点目前的要求已经开始周期性超越SAN的I/O容量——即它从磁盘存储系统读写数据的极限速度。
原因之一是每数据库1百万账户的分割策略，通常情况下的确可以将压力均分到各台服务器，但现实并非一成不变。比如第七台账户数据库上线后，仅仅7天就被塞满了，主要原因是佛罗里达一个乐队的歌迷疯狂注册。
某个数据库可能因为任何原因，在任何时候遭遇主要负荷，这时，SAN中绑定到该数据库的磁盘存储设备簇就可能过载。“SAN让磁盘I/O能力大幅提升了，但将它们绑定到特定数据库的做法是错误的。”Benedetto说。
最初，MySpace通过定期重新分配SAN中数据，以让其更为均衡的方法基本解决了这个问题，但这是一个人工过程，“大概需要两个人全职工作。”Benedetto说。
长期解决方案是迁移到虚拟存储体系上，这样，整个SAN被当作一个巨型存储池，不再要求每个磁盘为特定应用服务。MySpace目前采用了一种新型SAN设备——来自加利福尼亚州弗里蒙特的3PARdata。
在3PAR的系统里，仍能在逻辑上按容量划分数据存储，但它不再被绑定到特定磁盘或磁盘簇，而是散布于大量磁盘。这就使均分数据访问负荷成为可能。当数据库需要写入一组数据时，任何空闲磁盘都可以马上完成这项工作，而不再像以前那样阻塞在可能已经过载的磁盘阵列处。而且，因为多个磁盘都有数据副本，读取数据时，也不会使SAN的任何组件过载。
当2005年春天账户数达到1千7百万时，MySpace又启用了新的策略以减轻存储系统压力，即增加数据缓存层——位于Web服务器和数据库服务器之间，其唯一职能是在内存中建立被频繁请求数据对象的副本，如此一来，不访问数据库也可以向Web应用供给数据。换句话说，100个用户请求同一份资料，以前需要查询数据库100次，而现在只需1次，其余都可从缓存数据中获得。当然如果页面变化，缓存的数据必须从内存擦除，然后重新从数据库获取——但在此之前，数据库的压力已经大大减轻，整个站点的性能得到提升。
缓存区还为那些不需要记入数据库的数据提供了驿站，比如为跟踪用户会话而创建的临时文件——Benedetto坦言他需要在这方面补课，“我是数据库存储狂热分子，因此我总是想着将万事万物都存到数据库。”但将像会话跟踪这类的数据也存到数据库，站点将陷入泥沼。
增加缓存服务器是“一开始就应该做的事情，但我们成长太快，以致于没有时间坐下来好好研究这件事情。”Benedetto补充道。
里程碑五：2千6百万账户
2005年中期，服务账户数达到2千6百万时，MySpace切换到了还处于beta测试的SQL Server 2005。转换何太急？主流看法是2005版支持64位处理器。但Benedetto说，“这不是主要原因，尽管这也很重要；主要还是因为我们对内存的渴求。”支持64位的数据库可以管理更多内存。
更多内存就意味着更高的性能和更大的容量。原来运行32位版本的SQL Server服务器，能同时使用的内存最多只有4G。切换到64位，就好像加粗了输水管的直径。升级到SQL Server 2005和64位Windows Server 2003后，MySpace每台服务器配备了32G内存，后于2006年再次将配置标准提升到64G。
意外错误
如果没有对系统架构的历次修改与升级，MySpace根本不可能走到今天。但是，为什么系统还经常吃撑着了？很多用户抱怨的“意外错误”是怎么引起的呢？
原因之一是MySpace对Microsoft的Web技术的应用已经进入连Microsoft自己也才刚刚开始探索的领域。比如11月，超出SQL Server最大同时连接数，MySpace系统崩溃。Benedetto说，这类可能引发系统崩溃的情况大概三天才会出现一次，但仍然过于频繁了，以致惹人恼怒。一旦数据库罢工，“无论这种情况什么时候发生，未缓存的数据都不能从SQL Server获得，那么你就必然看到一个‘意外错误’提示。”他解释说。
去年夏天，MySpace的Windows 2003多次自动停止服务。后来发现是操作系统一个内置功能惹的祸——预防分布式拒绝服务攻击（黑客使用很多客户机向服务器发起大量连接请求，以致服务器瘫痪）。MySpace和其他很多顶级大站点一样，肯定会经常遭受攻击，但它应该从网络级而不是依靠Windows本身的功能来解决问题——否则，大量MySpace合法用户连接时也会引起服务器反击。
“我们花了大约一个月时间寻找Windows 2003服务器自动停止的原因。”Benedetto说。最后，通过Microsoft的帮助，他们才知道该怎么通知服务器：“别开枪，是友军。”
紧接着是在去年7月某个周日晚上，MySpace总部所在地洛杉矶停电，造成整个系统停运12小时。大型Web站点通常要在地理上分布配置多个数据中心以预防单点故障。本来，MySpace还有其他两个数据中心以应对突发事件，但Web服务器都依赖于部署在洛杉矶的SAN。没有洛杉矶的SAN，Web服务器除了恳求你耐心等待，不能提供任何服务。
Benedetto说，主数据中心的可靠性通过下列措施保证：可接入两张不同电网，另有后备电源和一台储备有30天燃料的发电机。但在这次事故中，不仅两张电网失效，而且在切换到备份电源的过程中，操作员烧掉了主动力线路。
2007年中，MySpace在另两个后备站点上也建设了SAN。这对分担负荷大有帮助——正常情况下，每个SAN都能负担三分之一的数据访问量。而在紧急情况下，任何一个站点都可以独立支撑整个服务，Benedetto说。
MySpace仍然在为提高稳定性奋斗，虽然很多用户表示了足够信任且能原谅偶现的错误页面。
“作为开发人员，我憎恶Bug，它太气人了。”Dan Tanner这个31岁的德克萨斯软件工程师说，他通过MySpace重新联系到了高中和大学同学。“不过，MySpace对我们的用处很大，因此我们可以原谅偶发的故障和错误。” Tanner说，如果站点某天出现故障甚至崩溃，恢复以后他还是会继续使用。
这就是为什么Drew在论坛里咆哮时，大部分用户都告诉他应该保持平静，如果等几分钟，问题就会解决的原因。Drew无法平静，他写道，“我已经两次给MySpace发邮件，而它说一小时前还是正常的，现在出了点问题……完全是一堆废话。”另一个用户回复说，“毕竟它是免费的。”Benedetto坦承100%的可靠性不是他的目标。“它不是银行，而是一个免费的服务。”他说。
换句话说，MySpace的偶发故障可能造成某人最后更新的个人资料丢失，但并不意味着网站弄丢了用户的钱财。“关键是要认识到，与保证站点性能相比，丢失少许数据的故障是可接受的。”Benedetto说。所以，MySpace甘冒丢失2分钟到2小时内任意点数据的危险，在SQL Server配置里延长了“checkpoint”操作——它将待更新数据永久记录到磁盘——的间隔时间，因为这样做可以加快数据库的运行。
Benedetto说，同样，开发人员还经常在几个小时内就完成构思、编码、测试和发布全过程。这有引入Bug的风险，但这样做可以更快实现新功能。而且，因为进行大规模真实测试不具可行性，他们的测试通常是在仅以部分活跃用户为对象，且用户对软件新功能和改进不知就里的情况下进行的。因为事实上不可能做真实的加载测试，他们做的测试通常都是针对站点。
“我们犯过大量错误，”Benedetto说，“但到头来，我认为我们做对的还是比做错的多。”
看了这么长的故事，让我们来总结一下：
引用
里程碑一：50万账户
只有两台Web服务器和一个数据库服务器。遇到数据库瓶颈，后改成数据库集群，1台Master数据库服务器写，2台Slave数据库服务器读。
里程碑二：1-2百万账户
数据库服务器开始受制于I/O容量——即它们存取数据的速度。解决方案就是数据库架构按照垂直分割模式设计，不同的数据库服务于站点的不同功能。还从存储设备与数据库服务器直接交互的方式切换到SAN（Storage Area Network，存储区域网络）——用高带宽、专门设计的网络将大量磁盘存储设备连接在一起，而数据库连接到SAN。
里程碑三：3百万账户
面临数据独立和数据共享问题，过度独立提高了出错率，个别应用增长太快，造成个别数据库压力巨大。选择“向上扩展”或“向外扩展”（译者注：Scale Up和Scale Out，也称硬件扩展和软件扩展）？尝试了硬件扩展后，发现软件扩展是必须的，这次采用分布式计算架构——它在物理上分布的众多服务器，整体必须逻辑上等同于单台机器。按照用户每百万一组分割，然后将各组的全部数据分别存入独立的SQL Server。以后还可以按照这种模式以更小粒度划分架构，从而优化负荷分担。
里程碑四：9百万到1千7百万账户
用ASP.NET重写程序，运行更有效率，节省了大量的服务器，但又遭遇了存储瓶颈问题，但站点目前的要求已经开始周期性超越SAN的I/O容量——即它从磁盘存储系统读写数据的极限速度。SAN让磁盘I/O能力大幅提升了，但将它们绑定到特定数据库的做法是错误的。长期解决方案是迁移到虚拟存储体系上，仍能在逻辑上按容量划分数据存储，但它不再被绑定到特定磁盘或磁盘簇，而是散布于大量磁盘，读写动作都由多个磁盘完成，就避免了磁盘存储系统读写数据的瓶颈。后增加数据缓存层，减轻存储系统压力，在Web服务器和数据库服务器之间，将频繁请求数据对象在内存中建立副本。
里程碑五：2千6百万账户
数据库换成了SQL Server 2005。2005版支持64位处理器，支持64位的数据库可以管理更多内存，更多内存就意味着更高的性能和更大的容量。
从上面五个里程碑中可以看出，碰到的主要问题，并不在Web服务上，而是数据库和磁盘IO的瓶颈上，增加数据缓存层，合理的设计规划数据库，减轻存储系统压力，才是大型高负载高并发网站系统架构需要解决的问题。
只有两台Web服务器和一个数据库服务器。遇到数据库瓶颈，后改成数据库集群，1台Master数据库服务器写，2台Slave数据库服务器读。
里程碑二：1-2百万账户
数据库服务器开始受制于I/O容量——即它们存取数据的速度。解决方案就是数据库架构按照垂直分割模式设计，不同的数据库服务于站点的不同功能。还从存储设备与数据库服务器直接交互的方式切换到SAN（Storage Area Network，存储区域网络）——用高带宽、专门设计的网络将大量磁盘存储设备连接在一起，而数据库连接到SAN。
里程碑三：3百万账户
面临数据独立和数据共享问题，过度独立提高了出错率，个别应用增长太快，造成个别数据库压力巨大。选择“向上扩展”或“向外扩展”（译者注：Scale Up和Scale Out，也称硬件扩展和软件扩展）？尝试了硬件扩展后，发现软件扩展是必须的，这次采用分布式计算架构——它在物理上分布的众多服务器，整体必须逻辑上等同于单台机器。按照用户每百万一组分割，然后将各组的全部数据分别存入独立的SQL Server。以后还可以按照这种模式以更小粒度划分架构，从而优化负荷分担。
里程碑四：9百万到1千7百万账户
用ASP.NET重写程序，运行更有效率，节省了大量的服务器，但又遭遇了存储瓶颈问题，但站点目前的要求已经开始周期性超越SAN的I/O容量——即它从磁盘存储系统读写数据的极限速度。SAN让磁盘I/O能力大幅提升了，但将它们绑定到特定数据库的做法是错误的。长期解决方案是迁移到虚拟存储体系上，仍能在逻辑上按容量划分数据存储，但它不再被绑定到特定磁盘或磁盘簇，而是散布于大量磁盘，读写动作都由多个磁盘完成，就避免了磁盘存储系统读写数据的瓶颈。后增加数据缓存层，减轻存储系统压力，在Web服务器和数据库服务器之间，将频繁请求数据对象在内存中建立副本。
里程碑五：2千6百万账户
数据库换成了SQL Server 2005。2005版支持64位处理器，支持64位的数据库可以管理更多内存，更多内存就意味着更高的性能和更大的容量。
从上面五个里程碑中可以看出，碰到的主要问题，并不在Web服务上，而是数据库和磁盘IO的瓶颈上，增加数据缓存层，合理的设计规划数据库，减轻存储系统压力，才是大型高负载高并发网站系统架构需要解决的问题。
现在ArthurXF本人正在搞PHP等技术培训，如果想学习的人可以跟我联系。另外培训的招生简章在这个网址，想了解的可以去看看。加我QQ：29011218交流也可。
PHP培训招生简章
作为一个网站管理员，我们经常会有需要知道当前什么人正在访问我们的网站，谁正在频繁的抓取我们网站的内容，什么搜索引擎正在抓取我们网站？面对这些问题，我们虽然可以去查看log日志文件，但是却不能让我们实时统计，不能给我们直观的统计数据。现在好了，有了apachetop这个工具就可以实时的跟踪log的变化，对网站管理帮助很大。Apachetop是一个apache的log实时监测程序，能查看访问者正在查看哪些文件，和访问者IP等信息。
首先，看看怎么安装：
安装成功之后，将在/usr/local/bin，加入apachetop命名文件，如果不能直接执行，请到这里来找。
一般使用方法：
下面是用法说明：
当执行之后，还有命令可以切换显示状态：
现在ArthurXF本人正在搞PHP等技术培训，如果想学习的人可以跟我联系。另外培训的招生简章在这个网址，想了解的可以去看看。加我QQ：29011218交流也可。
PHP培训招生简章
首先，看看怎么安装：
引用
cd /usr/ports/sysutils/apachetop
#如果你需要增加正则表达式等功能，则先执行配置命令，不需要则跳过
make config
make
make install
#如果你需要增加正则表达式等功能，则先执行配置命令，不需要则跳过
make config
make
make install
安装成功之后，将在/usr/local/bin，加入apachetop命名文件，如果不能直接执行，请到这里来找。
一般使用方法：
引用
# apachetop -f /var/log/httpd.access
下面是用法说明：
引用
ApacheTop v0.12.6 - Usage:
File options:
-f logfile open logfile (assumed common/combined) [/var/log/httpd-access.log]
(repeat option for more than one source)
URL/host/referrer munging options:
-q 保持请求字符串[no]
-l 所有的url小写[no]
-s num 保持url路径段数量 [all]
-p 在referrer前面保留协议 [no]
-r 保留每一个的主机/ip [no]
Stats options:
必须提供两个参数 default: [-T 30]
缺省设置为保持记录状态30秒，30秒后数据刷新了。为了提供更多的信息给我们分析，我们可以调节下面的参数。
-H hits 保持状态只到多少点击数
-T secs 保持状态只到多少秒
-d secs 刷新延迟时间[5]
-h 这个帮助。
File options:
-f logfile open logfile (assumed common/combined) [/var/log/httpd-access.log]
(repeat option for more than one source)
URL/host/referrer munging options:
-q 保持请求字符串[no]
-l 所有的url小写[no]
-s num 保持url路径段数量 [all]
-p 在referrer前面保留协议 [no]
-r 保留每一个的主机/ip [no]
Stats options:
必须提供两个参数 default: [-T 30]
缺省设置为保持记录状态30秒，30秒后数据刷新了。为了提供更多的信息给我们分析，我们可以调节下面的参数。
-H hits 保持状态只到多少点击数
-T secs 保持状态只到多少秒
-d secs 刷新延迟时间[5]
-h 这个帮助。
当执行之后，还有命令可以切换显示状态：
引用
ApacheTop version 0.12.6, Copyright (c) 2003-2004, Chris Elsworth
ONE-TOUCH COMMANDS
d : 切换urls/referrers/hosts显示模式开关
n : 切换hits & bytes或返回代码开关
h or ? : 帮助信息
p : (un)暂停显示 (冻结更新)
q : 退出 ApacheTop
up/down : 移动星标 up/down
right/left : 进入/退出逐条显示模式
子菜单:
s: 排序: [the appropriate menu will appear for your display]
r) requests R) reqs/sec b) bytes B) bytes/sec
2) 2xx 3) 3xx 4) 4xx 5) 5xx
t: 固定显示 ON/OFF:
u) urls r) referrers h) hosts
f: 使用过滤器:
a) add/edit menu c) clear all s) show active (not done yet)
a: ADD FILTER SUBMENU
u) to urls r) to referrers h) to hosts
ONE-TOUCH COMMANDS
d : 切换urls/referrers/hosts显示模式开关
n : 切换hits & bytes或返回代码开关
h or ? : 帮助信息
p : (un)暂停显示 (冻结更新)
q : 退出 ApacheTop
up/down : 移动星标 up/down
right/left : 进入/退出逐条显示模式
子菜单:
s: 排序: [the appropriate menu will appear for your display]
r) requests R) reqs/sec b) bytes B) bytes/sec
2) 2xx 3) 3xx 4) 4xx 5) 5xx
t: 固定显示 ON/OFF:
u) urls r) referrers h) hosts
f: 使用过滤器:
a) add/edit menu c) clear all s) show active (not done yet)
a: ADD FILTER SUBMENU
u) to urls r) to referrers h) to hosts
现在ArthurXF本人正在搞PHP等技术培训，如果想学习的人可以跟我联系。另外培训的招生简章在这个网址，想了解的可以去看看。加我QQ：29011218交流也可。
PHP培训招生简章
ipcs - 分析消息队列、共享内存和信号量
ipcs - report status of interprocess communication facilities
ipcs displays certain information about active interprocess communication facilities. With no options, ipcs displays information in short format for the message queues, shared memory segments, and semaphores that are currently active in the system.
它的语法：
ipcs [-mqs] [-abcopt] [-C core] [-N namelist]
-m 输出有关共享内存(shared memory)的信息
-q 输出有关信息队列(message queue)的信息
-s 输出信号量(semaphore)的信息
# ipcs -m
IPC status from as of 2007年04月10日 星期二 18时32分18秒 CST
T ID KEY MODE OWNER GROUP
Shared Memory:
m 0 0x50000d43 --rw-r--r-- root root
m 501 0x1e90c97c --rw-r----- oracle dba
ipcrm - 删除ipc(清除共享内存信息)
现在ArthurXF本人正在搞PHP等技术培训，如果想学习的人可以跟我联系。另外培训的招生简章在这个网址，想了解的可以去看看。加我QQ：29011218交流也可。
PHP培训招生简章
ipcs - report status of interprocess communication facilities
ipcs displays certain information about active interprocess communication facilities. With no options, ipcs displays information in short format for the message queues, shared memory segments, and semaphores that are currently active in the system.
引用
它的语法：
ipcs [-mqs] [-abcopt] [-C core] [-N namelist]
-m 输出有关共享内存(shared memory)的信息
-q 输出有关信息队列(message queue)的信息
-s 输出信号量(semaphore)的信息
# ipcs -m
IPC status from
T ID KEY MODE OWNER GROUP
Shared Memory:
m 0 0x50000d43 --rw-r--r-- root root
m 501 0x1e90c97c --rw-r----- oracle dba
ipcrm - 删除ipc(清除共享内存信息)
引用
它的语法：
ipcrm -m|-q|-s shm_id
-m 输出有关共享内存(shared memory)的信息
-q 输出有关信息队列(message queue)的信息
-s 输出信号量(semaphore)的信息
shm_id 共享内存id
#ipcrm -m 501
ipcrm -m|-q|-s shm_id
-m 输出有关共享内存(shared memory)的信息
-q 输出有关信息队列(message queue)的信息
-s 输出信号量(semaphore)的信息
shm_id 共享内存id
#ipcrm -m 501
现在ArthurXF本人正在搞PHP等技术培训，如果想学习的人可以跟我联系。另外培训的招生简章在这个网址，想了解的可以去看看。加我QQ：29011218交流也可。
PHP培训招生简章
top监控工具可以显示CPU占用率为前几位的进程，并提供CPU的实时活动情况，及内存使用情况。
top监控命令在FreeBSD上的使用
top监控工具可以显示CPU占用率为前几位的进程，并提供CPU的实时活动情况
屏幕控制命令
交换方式下，可以使用以下命令控制top
顺序显示下面三个常规的信息
一． 系统信息:
last pid: 22228; load averages: 0.25, 0.97, 1.56 up 44+03:25:56 21:39:36
274 processes: 3 running, 259 sleeping, 12 zombie
CPU states: 2.9% user, 0.0% nice, 4.2% system, 0.4% interrupt, 92.5% idle
Mem: 483M Active, 120M Inact, 222M Wired, 25M Cache, 112M Buf, 153M Free
Swap: 2048M Total, 143M Used, 1905M Free, 6% Inuse
首部的几行显示系统的几个信息，其中包括:
+ Load averages:1分钟、5分钟和15分钟内运行的负载平均数
+ system:系统名和当前日期.
一般来说只要每个CPU的当前活动进程数不大于 3那么系统的性能就是良好的，如果每个CPU的任务数大于5，
那么就表示这台机器的性能有严重问题
+ 最近一次更新时存在的进程总数，并分别列出run(运行)、sleep(睡眠)、idle（停止）和zomb(‘僵尸')状态的进程数
+ CPU state:用户占用时间的百分比、系统占用CPU时间的百分比、被nice命令改变优先级的任务占用的CPU时间百分比、以及CPU空闲时间的百分比。
（被nice命令改变优先级的任务仅指那些nice值为负的任务）。花费在被nice命令改变优先级的任务上的时间也将被计算在系统和用户时间内，因此整个时间加起来可能会超过百分之百
二．内存信息
Memory: 610008K (24424K) real, 995344K (30304K) virtual, 12588K free Page# 1/4
Memory:关于内存使用情况的统计，包括实际（real）内存的活动值/总值，虚拟（virtual）内存的使用值/总值，剩余的内存。
DESCRIPTION OF MEMORY
Mem: 9220K Active, 1032K Inact, 3284K Wired, 1MB Cache, 2M Buf, 1320K
Free Swap: 91M Total, 79M Free, 13% Inuse, 80K In, 104 K Out
K: Kilobyte(K)
M: Megabyte(兆)
%: 1/100(百分比)
Active:
活动页的数目
Inact: 非活动页的数目
Wired: 已经被写入页的数目, 包括缓存文件数据页码
Cache: 被用于 VM-level 磁盘缓冲的页的数目
Buf: 被用于 BIO-level 磁盘缓冲的页的数目
Free: 空闲页
Total: 总的可使用交换区
Free: 总共空闲的交换区
Inuse: 交换区的使用情况
In: pages paged in from swap devices (最近的时间间隔)
Out: pages paged out to swap devices (最近的时间间隔)
三．进程信息
CPU PID USERNAME PRI NI SIZE RES STATE TIME %WCPU %CPU COMMAND
1 33 root 152 20 0K 0K run 153:43 1.18 1.18 vxfsd
0 1751 root 154 20 2500K 868K sleep 2084:19 0.52 0.52 ARMServer
0 1730 root 154 20 4500K 332K sleep 1664:55 0.44 0.44 acactmgr
列出系统里每一个处理器的信息,当信息在一个屏幕内无法显示时,会被分成多个屏幕显示,可以前面提到l,k和t命令查看
（1）CPU：处理器号（仅当多处理器系统时列出）
（2）PID：进程号
（3）USERNAME：用户名
（4）PRI:任务的优先级
（5）NICE：任务的nice值，一个具有较低值的进程在系统上将具有优先权。可以通过改变nice值提高某些进程速度，但是这实际上是一种交易，因为那些nice值被升高的进程此时将运行得很慢。
（6）SIZE：任务的代码加上数据再加上栈空间的大小。
（7）RES：任务使用的物理内存的总数量。
（8）STATE：任务的状态
（9）TIME：自任务开始时使用的总CPU时间,单位为秒，如153:43，对应是153秒43毫秒
（10）%WCPU：进程的CPU利用率权重百分比
（11）%CPU：进程的原始的CPU利用率百分比，自上一次屏幕刷新以来任务占用CPU 时间的份额
（12）COMMAND：启动进程的命令名。如果名字太长而不能在一行显示时，它将被截短
现在ArthurXF本人正在搞PHP等技术培训，如果想学习的人可以跟我联系。另外培训的招生简章在这个网址，想了解的可以去看看。加我QQ：29011218交流也可。
PHP培训招生简章
top监控命令在FreeBSD上的使用
top监控工具可以显示CPU占用率为前几位的进程，并提供CPU的实时活动情况
引用
语法：top [-s time] [-d count] [-q] [-h] [-n number] [-f filename] [-o field][-U usename]
-S 将系统进程信息也显示到屏幕上，默认情况下，top不显示系统进程的信息
-b 使用"batch"方式运行top。在此种方式下，所有来自终端的输入都将被忽略，但交互键(比如^C and ^\)
依然起使用。这是运行top输出到亚终端或输到非终端的默认运行方式
-i 使用交互运行top程序，在此种方式下，命令会被进程立即被处理。不管命令是不是能被top所理解执行，
屏幕都将立即更新。这是top的默认运行方式。
-I 不显示空闲进程，在默认情况下，top连同空闲进程的信息一同输出。
-t 不显示top进程自己
-n 不以交互方式使用top命令，作用同"batch"方式。
-s time 设置屏幕刷新的延时，单位为秒，默认值5秒
-d count 设置屏幕刷新的次数，刷新显示完count次后退出
-q 如果经过nice授权，使用-q可以使top运行的更快一些，这样，在系统反应缓慢的时候，可以会更快的找到存在的问题。此选项在FreeBSD下只有root可以使用
-n number 设置每一屏幕显示的进程数目，number值超过进程最大数目，则设置无效
-u 用显示User ID代替username，提高命令运行速度
-v 显示程序版本号后，立即退出。如果要在top运行时查看版本号，输入"?"
-o 以指定的字段排序显示进行信息。字段名必须为输入在屏幕的可见列的名字，而且必须是小写。
比如"cpu"、"size"、"res"与"time",但不同的操作系统间有许多的不同。注意不是每个UNIX操
作系统都支持此选项。
-U 只显示属于后面所跟用户名的进程的信息
-S 将系统进程信息也显示到屏幕上，默认情况下，top不显示系统进程的信息
-b 使用"batch"方式运行top。在此种方式下，所有来自终端的输入都将被忽略，但交互键(比如^C and ^\)
依然起使用。这是运行top输出到亚终端或输到非终端的默认运行方式
-i 使用交互运行top程序，在此种方式下，命令会被进程立即被处理。不管命令是不是能被top所理解执行，
屏幕都将立即更新。这是top的默认运行方式。
-I 不显示空闲进程，在默认情况下，top连同空闲进程的信息一同输出。
-t 不显示top进程自己
-n 不以交互方式使用top命令，作用同"batch"方式。
-s time 设置屏幕刷新的延时，单位为秒，默认值5秒
-d count 设置屏幕刷新的次数，刷新显示完count次后退出
-q 如果经过nice授权，使用-q可以使top运行的更快一些，这样，在系统反应缓慢的时候，可以会更快的找到存在的问题。此选项在FreeBSD下只有root可以使用
-n number 设置每一屏幕显示的进程数目，number值超过进程最大数目，则设置无效
-u 用显示User ID代替username，提高命令运行速度
-v 显示程序版本号后，立即退出。如果要在top运行时查看版本号，输入"?"
-o 以指定的字段排序显示进行信息。字段名必须为输入在屏幕的可见列的名字，而且必须是小写。
比如"cpu"、"size"、"res"与"time",但不同的操作系统间有许多的不同。注意不是每个UNIX操
作系统都支持此选项。
-U 只显示属于后面所跟用户名的进程的信息
屏幕控制命令
交换方式下，可以使用以下命令控制top
引用
^L - 刷新屏幕
q - 退出
h or ? - 显示帮助
d - 修改刷新显示的次数
e - 显示最近"kill"或"renice"命令所产生的错误
i - 显示/不显示处于空闲的进程
I - 作用同 'i'
k - kill 进程; 发送一个信号到某个进程列表
n or # - 修改显示进程的数目
o - 以特定的字段排序 (pri, size, res, cpu, time)
r - renice 一个进程
s - 修改输入的更新时间
u - 只显示属于某个用户的进程 (+ selects all users)
q - 退出
h or ? - 显示帮助
d - 修改刷新显示的次数
e - 显示最近"kill"或"renice"命令所产生的错误
i - 显示/不显示处于空闲的进程
I - 作用同 'i'
k - kill 进程; 发送一个信号到某个进程列表
n or # - 修改显示进程的数目
o - 以特定的字段排序 (pri, size, res, cpu, time)
r - renice 一个进程
s - 修改输入的更新时间
u - 只显示属于某个用户的进程 (+ selects all users)
顺序显示下面三个常规的信息
一． 系统信息:
last pid: 22228; load averages: 0.25, 0.97, 1.56 up 44+03:25:56 21:39:36
274 processes: 3 running, 259 sleeping, 12 zombie
CPU states: 2.9% user, 0.0% nice, 4.2% system, 0.4% interrupt, 92.5% idle
Mem: 483M Active, 120M Inact, 222M Wired, 25M Cache, 112M Buf, 153M Free
Swap: 2048M Total, 143M Used, 1905M Free, 6% Inuse
首部的几行显示系统的几个信息，其中包括:
+ Load averages:1分钟、5分钟和15分钟内运行的负载平均数
+ system:系统名和当前日期.
一般来说只要每个CPU的当前活动进程数不大于 3那么系统的性能就是良好的，如果每个CPU的任务数大于5，
那么就表示这台机器的性能有严重问题
+ 最近一次更新时存在的进程总数，并分别列出run(运行)、sleep(睡眠)、idle（停止）和zomb(‘僵尸')状态的进程数
+ CPU state:用户占用时间的百分比、系统占用CPU时间的百分比、被nice命令改变优先级的任务占用的CPU时间百分比、以及CPU空闲时间的百分比。
（被nice命令改变优先级的任务仅指那些nice值为负的任务）。花费在被nice命令改变优先级的任务上的时间也将被计算在系统和用户时间内，因此整个时间加起来可能会超过百分之百
二．内存信息
Memory: 610008K (24424K) real, 995344K (30304K) virtual, 12588K free Page# 1/4
Memory:关于内存使用情况的统计，包括实际（real）内存的活动值/总值，虚拟（virtual）内存的使用值/总值，剩余的内存。
DESCRIPTION OF MEMORY
Mem: 9220K Active, 1032K Inact, 3284K Wired, 1MB Cache, 2M Buf, 1320K
Free Swap: 91M Total, 79M Free, 13% Inuse, 80K In, 104 K Out
K: Kilobyte(K)
M: Megabyte(兆)
%: 1/100(百分比)
Active:
活动页的数目
Inact: 非活动页的数目
Wired: 已经被写入页的数目, 包括缓存文件数据页码
Cache: 被用于 VM-level 磁盘缓冲的页的数目
Buf: 被用于 BIO-level 磁盘缓冲的页的数目
Free: 空闲页
Total: 总的可使用交换区
Free: 总共空闲的交换区
Inuse: 交换区的使用情况
In: pages paged in from swap devices (最近的时间间隔)
Out: pages paged out to swap devices (最近的时间间隔)
三．进程信息
CPU PID USERNAME PRI NI SIZE RES STATE TIME %WCPU %CPU COMMAND
1 33 root 152 20 0K 0K run 153:43 1.18 1.18 vxfsd
0 1751 root 154 20 2500K 868K sleep 2084:19 0.52 0.52 ARMServer
0 1730 root 154 20 4500K 332K sleep 1664:55 0.44 0.44 acactmgr
列出系统里每一个处理器的信息,当信息在一个屏幕内无法显示时,会被分成多个屏幕显示,可以前面提到l,k和t命令查看
（1）CPU：处理器号（仅当多处理器系统时列出）
（2）PID：进程号
（3）USERNAME：用户名
（4）PRI:任务的优先级
（5）NICE：任务的nice值，一个具有较低值的进程在系统上将具有优先权。可以通过改变nice值提高某些进程速度，但是这实际上是一种交易，因为那些nice值被升高的进程此时将运行得很慢。
（6）SIZE：任务的代码加上数据再加上栈空间的大小。
（7）RES：任务使用的物理内存的总数量。
（8）STATE：任务的状态
（9）TIME：自任务开始时使用的总CPU时间,单位为秒，如153:43，对应是153秒43毫秒
（10）%WCPU：进程的CPU利用率权重百分比
（11）%CPU：进程的原始的CPU利用率百分比，自上一次屏幕刷新以来任务占用CPU 时间的份额
（12）COMMAND：启动进程的命令名。如果名字太长而不能在一行显示时，它将被截短
现在ArthurXF本人正在搞PHP等技术培训，如果想学习的人可以跟我联系。另外培训的招生简章在这个网址，想了解的可以去看看。加我QQ：29011218交流也可。
PHP培训招生简章
