2008 年我的 Wish List:
1) 自己的浴室。其实说的是房子。虽然非常不喜欢杭州这个城市，还是准备买房子了。住在租来的房子里总有自己不喜欢的地方，还不能轻易改动。就像软件的源代码不在自己手里一样。
2) 有台自己的主机，托管。解决 BLog 速度无比慢的老问题。
3) Blog Google Pagerank 6。 本来 07 年有希望的，可是突然绝大多数 Blog PR 值都降级了，我的虽然幸免，但没升的机会了。
4) 一台轻便的移动计算设备。如果 3G 真的在 2008 年来临的话，我希望能在一些场合扔掉那个沉重的 D620 笔记本。Nokia 的 N800 看起来不错。
这几条，有的重要，有的类似鸡毛蒜皮，其实生活就是鸡毛蒜皮的事情组成的。
前几天看了去年的 Wishlist，没有一条得到了实现。可见愿望毕竟是愿望。
--EOF--
向阅读我 Blog 的朋友道一声：新年快乐！
例行的一年非正式个人总结开始了。在这一年的最后一天，总要写点什么。先回顾一下 2006 年末的总结和计划吧。
有幸成为国内第一拨 Oracle ACE，8 月份 在上海参加了 Oracle Open World 会议。在 ITpub 的年度奖项评选中得了个“数据库大版最佳版主”奖，也值得欣慰一下。相比去年，还算是有了不少走出去的场合，“交流”也会是我 08 年的一个重点关键词。
08 年打算控制一下阅读量，不算每天在网上的大量阅读，我还读了大量的小说，历史小说居多，最近几个月又读起了科幻，这是个很消耗时间的事情，也非常容易带来眼部疲劳。我家今年多添了一只小猫，小黑猫，一直没有正式的名字。很想起个比“猫泽西”还拉风的名字，谁给出个主意 ?
这一年，如果要自己评价工作情况: 我觉得可以用"兢兢业业"这四个字吧，总体来看比较顺利。至于公司呢，支付宝发展顺风顺水，阿里集团更是风生水起，我有幸作为其中的一个小兵，过河卒子，奋勇向前。
好多朋友说起个人发展来都基本会说到"个人创业"，其实做好当下这份工作也是"创业"，给自己打工和被别人打工有什么区别呢?
2008 就要来了，奥运，和我不沾边，谁知道奥运过后中国的经济会怎样... 明年的一点计划：
一年又一年...
--EOF--
这个圣诞对 SCO （Santa Cruz Operation）公司高层来说肯定不轻松，Nasdaq 通知信确认 SCO 将从12月27日被摘牌，这是一场终于到来的噩梦。IBM、红帽子、Novell 肯定会对这事儿拍手称快！
当年 Linux 风头正健的时候 SCO 居然下嫁给 Caldera ，无数人惊呼，"Unix 已死，Linux 当道"，真实情况却并不是这样。没多久，Caldera 就发现 Linux 在市场实在不受待见，用户也不买 “Caldera” 这个名字的账，结果 2002 年又更名回 SCO。当时还拉了一堆虾兵蟹将搞 “统一 Linux” (United Linux) ，也是属于“十八路诸侯讨董卓”的路数，没过多久就瓦解了。SCO Unix 在市场上属于找不到北的那种的，基本上比 Novell 还没感觉。
SCO 这几年混的也太臭，简直一副无赖嘴脸，仗着自己"有" UNIX System V 的代码版权，对 IBM 的 10 亿美金诉讼赔偿简直是"碰瓷"行径，只不过 IBM 也不是善茬儿，陪你玩到底；SCO 还不甘心，干脆把大家都拉进来，四面数敌，到处勒索，结果光是诉讼就搞得满头是包。最富有戏剧性的是今年 8 月份，一纸裁决下来，宣判 UNIX 与 UnixWare 属于 Novell 的，这对 SCO 简直是釜底抽薪，只有缴枪的份儿了。
想当年，在国内， SCO 占据了国内 Unix 绝大部分市场，那时候 SCO Unix 相关的图书也是卖到洛阳纸贵。中软和东方龙马是相当大的两个分销商，而这两个公司也走出了国内无数的 Unix 技术人才（这两个公司的发展状况和 SCO 倒是也有几分相似之处)。前几天和一位中软前同事吃饭，谈及此事，仍是不胜唏嘘。我刚毕业的时候，在中软的一家子公司工作，一部分业务就是操作系统分销，当时就感觉这玩意儿有点过时，但是国内很多单位(比如邮政)对 SCO Unix （主要是 Open Server)依赖性还是很大，我算是赶上了末班车，说起来，对 SCO 也算是有很深的感情啊。
市场是残酷的，时间也是残酷的。SCO 快死掉了，多少年后我也会怀念 OpenServer、Unixware 这些产品。
--EOF--
--EOF--
最近在 ITpub 上有几个讨论 IO 的帖子很热闹，其中一个讨论中 Biti 说"响应时间在 10ms 左右能达到的最大 IOPS 能力，是系统 IO 能力的一个最重要指标" ,下面好多网友不知道这个 10ms 怎么来的，以及为什么是 10ms .
其实如果你熟读 Oracle 手册的话，你会发现 10g 中已经涉及到这个 “10ms” 的信息了，而且，侧面透漏出很多潜在的细节。
在 Oracle 10g 中有一个新的参数： DBIO_EXPECTED ，这个参数指 DB 平均读取一个 数据库块的时间，单位是毫秒(millisecond)。由 ADDM（ Automatic Database Diagnostics Monitor）用以分析系统 IO 性能的参考值。默认是 10ms ，之所以取这个值，是因为当前企业内投入使用的硬盘（存储）一般一个 IO 时间(读取一个 DB 块)大约在 10 ms 之下，超出 10 ms 一般意味着在 IO 跑得有点费劲了。这个 10ms 是个经验值，但这个经验值是有来由的。
有些慢速硬盘，比如希捷 Barracuda® ES.2，寻道时间接近 10毫秒，一些老一点的 SATA 盘肯定更慢了；而 Cheetah® 15K.5 则大约只是 3ms-4ms 的样子（DBA没事的时候不妨看看硬盘厂商的白皮书，挺好玩的)。一个 DB 系统上线时，测试一下 IO 基准能力还是必要的。注意测试的时候出现的"拐点"，意味着这个时候的 IO 响应时间是至关重要的，因为这个时候 IO 即使有应用Cache、 数据库 Cache、（主机 Cache）、存储 Cache，也还是有大量 IO 压在了后面的磁盘上，如果磁盘的 IO 到了峰值，IO 层的能力也就到了峰值了(特定响应时间下的最大 IOPS)。多数系统上，应该在 10ms 附近。所以，你盯着 DB 上离散读的平均响应时间，到了 10ms 意味着快撑不住了。
要如实使用 ADDM 衡量 IO 状况，DBIO_EXPECTED 参数还是需要作一点调整的。要注意这个参数并不是初始化参数，如果需要重新设定，则需要提交如下语句修改：
EXECUTE DBMS_ADVISOR.SET_DEFAULT_TASK_PARAMETER('ADDM', 'DBIO_EXPECTED', 4000);
上面的数值单位是微秒。
数据库 IO 是一个非常有意思的话题，本来想写一系列的东西。结果这篇写出来发现不伦不类。权作抛砖吧。
--EOF--
今天又有同事遭遇小偷了，幸运的是小偷没得手。后来同事跟我说，那两个小偷在他后面还跑的气喘吁吁，估计跟着他跑了一条街才找机会下手，做小偷也不容易，看人家多敬业! 下午的时候，合作伙伴的朋友来访，告诉我他的 iPhone 前几天在车上丢了。再前一段时间也有个同事差点在路口被抢走 iPhone。
其实最近一段时间，已经有不少同事不断爆料，就在公司楼下，小偷异常猖獗。快到了明抢的地步了。
这一切说明了什么? 快过年了，小偷也想捞一票回家啊！
杭州本地小偷似乎不多，多数都是从外地杀进来的，据说看面貌很像维族兄弟，我相信维族兄弟们绝大多数是善良的，但是不乏也有少数败类败坏了维族同胞声誉。提及“维族”很容易被误解为民族歧视(如果说新疆人更有人不愿意听，说中国人、黄种人的话还没人知道具体特征)，别误会，汉族里的小偷数量肯定更他妈的多，我当年在东北老家就被家乡人民偷了一次呢，但个体不能代表全体。小偷都是类似的，只有被偷的人才是不同的。
元旦，春节，也算小偷的两个黄金周了，一年就赶着这段时间出活呢，所以大家多加一点小心。走在路上，把包背在身前，这样子有点傻，但也比丢了东西强。上天桥、过马路，手最好在口袋里抓着手机、按着钱包，即使现在手机便宜，可丢了的话，联系人重新输入不也是挺麻烦? 要是里面有个隐私啥的就更不好办了。
愿天下无贼！
--EOF--
2007 年就快过去了。这一年中， Web 2.0 应用对我的网络生活影响程度更大了一点。回顾一下，除了过去经常用的 del.icio.us、Flickr 等"老一辈“的 Web 2.0 服务外, 今年新熟悉了几个 Web 2.0 服务。
Twitter 刚上手不知道怎么玩，但是玩起来还有点容易上瘾。必须要承认 Twitter 是个时间杀手，我过去也担心这东西带来的信息过载，有的时候会有比较大的信息噪音，比如那些绑定了 Feed 到 Twitter 上的朋友，对于 Feed 通知更新太频繁的我都屏蔽掉了，现在尽管每天接收大量 Twitter 的 Updates ，但总体感觉信息还是比较有质量。
顺便说一下，我用 TwitterFox 这个 Firefox 插件。用 IM 收发更新容易受到被动干扰。有些担心有一天 Twitter 会被阻尼，但我不打算用国内的克隆版，使用这些 服务也是为了体验创新的产品设计。
在尝试 LinkedIn 之前，我是若邻 (Wealink.com) 的用户，但若邻的整体用户氛围现在非常让我比较反感，尤其是很多人打着"猎头"的头名来套瓷，还有社区内的很多人一天到晚的转发帖子，信息噪音太大了。LinkedIn 上的用户还是比较规矩的，没事也没人来干扰你。
LinkedIn 是《连线》杂志评选的 2008年十大最值得关注创业公司，符合我要用就用同类站点中最好的习惯，你总不想某天找不到自己辛苦积累的信息吧? 之所以起用 LinkedIn 这样的服务，还是觉得有必要积累一点个人资本，认识一些国内外业内的朋友，互相通通气。我在 LinkedIn 上的 Profile 连接超过了 75 个，估计还能逐渐增加一些，话说回来，LinkedIn 上 Google 的员工，平均每人也只有 47个联系人“。车东在上面有超过 500 个连接，可以作猎头了。
其实面临求职的朋友不妨在 LinkedIn 或者类似的服务上维护一份自己的简历，事半功倍。
其他的 SNS 服务，如 MySpace 或者是 Facebook ，我不打算用。没那个精神头了。
自从 Feedburner 被阻尼了之后，不得不抛弃客户端工具 GreatNews，而起用在线 RSS 阅读工具，另外一个考虑是性能问题，订阅 Feed 超过 1000 个后，GreatNews 更新非常消耗本地资源。虽然抓虾也不错，但我基本上是用抓虾看看热文，大部分的阅读还是在 Google Reader 内，看到不错的文章就 Share 一下，通过 RSS 集成到 CNOUG.net 上，便于 DBA 圈子内的其他朋友也及时看到，共享嘛。
Google Reader 最近的好友间阅读共享功能也很有意思，虽然多数人都在质疑这个功能有泄漏隐私之嫌。我个人觉得可以通过算法来调整这个设计上的漏洞。Google 不是一项强调数据说话麽? 那就来点更智能化的东西吧。
这两天也在尝试 Soup.io 和 FriendFeed 这两个东西，直觉中明年要启用其中的一个。你在去年尝试并喜欢那些 Web 2.0 服务? 说一下吧
--EOF--
这是一篇迟到的非标准书评。收到人邮社刘江老师寄来的《Oracle 9i & 10g 编程艺术》好久了，只不过绝大多数时间这本书都不在我手旁，也就没时间读完。好多同事抢去看，此书受欢迎程度可见一斑。
去年我就曾经写过一篇关于这本书的小道消息。Thomas Kyte 大叔 早年被引入的 Oracle Expert one-on-one(《Oracle专家高级编程》)可以算得上对国内 DBA 圈子影响最大的一本图书，在市场上也销售得不错。不过那本书的一大问题是翻译质量比较糟糕，副作用是带来了不少辞不达意的翻译术语，比如"封锁"，该书糟糕的装帧质量也让不少读者比较痛苦，好多人都是干脆把书拆开，自动分成上下两册来看。
我曾经给刘江老师出过不少馊主意，其中最馊的一个就是怂恿他干脆重新出版一次《Oracle专家高级编程》(因为那时候 Wrox 的大部分图书都到了 APress 的旗下，版权是能搞定的)，但他担心该书出版的时间太久，市场上没有后劲了，也就作罢。因为我一直订阅 Tom 的 Blog, 也算是第一时间知道他在进行新书的写作，就把这个消息通知了刘江，英文版本出版后没多久，刘老师告诉我邮电出版社拿到了 Tom 新作 Expert Oracle Database Architecture 的翻译版权。当时这本书应该也引起了不少国内出版社的注意，但最终"得手"的是邮电社，一本好书会被有眼光的编辑一直盯个好几年。下手的时候果断也是必要的。
说了这么多，还没说到这本书到底内容如何。"这本 Expert Oracle Database Architecture 是 Tom 在 《Oracle专家高级编程》 的基础之上的解构之作，内容上的变动相当大。不但加入了最新的 10g 的内容, 还作了很多技术补充" ，这里我要纠正一下这个"解构"，应该套用现在的流行技术词汇"重构"，完全是一本"重构"的图书，针对图书内容的重构。
"锁"与"并行"这两个主题分别独立成章叙述，前一章是后一章必不可少的铺垫。要我推荐章节的话，应该首推 第 8 章 事务，不只是 DBA 要看，开发人员、架构师更要看。要设计一个高可靠、可扩展的应用，架构师甚至都要比 DBA 清楚事务。把复杂的东西用人人可作的代码用例展示出来，这是 Tom 拿手的本事。所以，看起来会让你不那么累。
最大的变化是 第十二章 数据类型，这是完全新增的一个章节，这一章中关于时间相关的数据类型讲述非常精彩。另外一个有趣的话题是 LOB，尽管现在用 LOB 字段的场景可能不那么多了，但是用过的人怕是多少都吃过这东西的亏。
如果非要挑毛病的话，我觉得对 分区表的讲述可能不够那么深入，以 Tom 的功力，应该对分区多讲一点，随着计算环境的变迁，OLTP 怕是都已经纷纷采用分区功能了。
翻译上基本上没啥大毛病，很多细节注意的都比较到位，记得 "Lock" 、"Latch" 翻译做什么，还单独做过讨论来着。甚至 前言中的 "Think different" 应该怎么翻译，也做过仔细推敲。从阅读体验来看，这本书的装帧质量很不错。排版改进非常非常多，虽说没办法和英文原版比，但是相比国内技术类图书，应该是不差的了。
如果你需要一本纸版的Oracle 图书，不妨考虑一下这本《Oracle 9i & 10g 编程艺术》。如果你已经买了这本书，多读几遍。书的价值不是由定价体现出来的，而是由你从这本书里学到多少东西决定的。最后，这些话...一般人儿我不告诉他......
--EOF--
补充: 下载部分英文章节试读.
看到这篇 2007 抓虾最热 50 篇文章分析，甚感惭愧。没一篇是自己写的。翻了一下抓虾上被推荐的文章列表，看看这一年抓虾用户给了 DBAnotes.net 多大的关注程度。
重新安装系统后的几件事情 >> 推荐数：70
本想写给自己备忘的一篇文章反而收到了最多的关注程度(不过即使最多也没超过 100 个推荐)。始料未及。或许是越简单的东西反而越普适.
WikiPedia 技术架构学习分享 >> 推荐数：51
架构类文章被推荐最多的一篇，之所以受到了更多关注怕还是沾了 WikiPedia 名头的光。
YouTube 的架构扩展 >> 推荐数：43
Google 收购 YouTube 后，迫不及待的把 YouTube 纳入自己体系架构中。YouTube 也是大树底下好乘凉。
财帮子（caibangzi.com）网站架构 >> 推荐数：27
采访了财帮子的 Meng Yan 后整理的资料。07 年财经类站点很火。08 年相信他们会更有机会。这也是唯一一篇爆料国内网站架构的文章。
WordPress 对 Gravatar 进行的优化 >> 推荐数：22
WordPress 收购 Gravatar 后，干了啥好事？
Yahoo！社区架构 >> 推荐数：30
关于雅虎技术背景的爆料。
Twitter 架构扩展：100 倍性能提升 >> 推荐数：30
Twitter 是 2007 年我用的比较多的服务了。这个站点现在还需要不停的扩展
Internet Archive 的海量存储浅析 >> 推荐数： 13
从写这篇分析开始，我有了写更多系统架构分析文章的念头。
Unix 速成小法 >> 推荐数：35
这篇和另一篇 GNU 核心工具 遥相呼应。算是我对 Unix 使用中的一点感悟。
Bash Shell 快捷键的学习使用 >> 推荐数：33
Shell 学习笔记，备忘。俗语说，好记性不如烂笔头，诚然。
GNU 核心工具 >> 推荐数：18
关于GNU Core Utilities 的小小介绍。
从 MySQL 迁移到 Oracle (傻瓜篇) >> 推荐数：16
从 Oracle 迁移到 MySQL 的文章很多，从 MySQL 迁移到 Oracle 的文章则很少。本文算是抛砖引玉。
Web 2.0 站点扩展性问题随感 >> 推荐数：27
Web 2.0 站点扩展性问题越来越突出，已经成为制约 Web 2.0 发展的一个障碍. 一点想法以及探讨。
Windows 上最好用的 GTD 工具是哪一个? >> 推荐数：21
GTD 工具林林总总，可最好用的是哪一个？怕是没有最好，只有哪个合适而已。
G FW 三定律 >> 推荐数：22
这篇文章被关注绝对不是因为写的好，而是因为痛恨 GF W 的人太多了。
推荐本站在 del.icio.us 收藏最多的文章 >> 推荐数：28
一点题外话：
1）抓虾数据仍有潜力可挖掘。像我的最被关注的帖子，如果能给自动做个分析该有多好?
2) del.icio.us 和 抓虾用户兴趣点多有重合之处。但普及类的文章在抓虾上怕是更受关注。
3) 被推荐多或者被收藏多的文章不一定得到比较多的评论
不早了，改天想起来再写
--EOF
公司有个老传统节目叫做“国王与天使“，随机抽签，"天使"要给"国王"送个小礼物。我的天使给我送来了什么? 一双袜子，仔细一看，还是女袜...说看我的名字以为我是女孩子，问题是，有名字这么难听的女孩子麽? 不管怎么样，谢谢这位同事！另外，每个人都是自己的天使，圣诞快乐!
这两天比较忙，忘了我自己也当”天使“这个事情，查找一下才知道我的”国王“远在北京，只好通过 IM 问候一下。
翻看了一下 我在 2007 年的 Wish List，居然一个都没实现。看来 Wish 还不是现实。
--EOF--
如果没有 37signals ，恐怕也没有 RoR 的如此流行。37signals 对于很多 Geek 来说，是一家非常迷人的公司。他们是网络上的另类新星。
37Signals 在 Signal vs. Noise 上披露了比较详细的运营数据，Ask 37signals: Numbers?
这包括 Basecamp、Highrise、BackPack、Campfire总的数据统计。总的用户量其实并不多，只有 200 万。
这些数据存放在 Amazon S3 上，37Signals 用了这个服务已经一年多了，他们对此比较满意。事实上，Amazon S3 已经成为 Web 2.0 分布式存储的既定事实的解决方案。
关心 ROR 以及具体一些策略具体实现的朋友不防去看看那个帖子下面的留言。
之前还真的很少有听说哪家 Web 2.0 公司部署 XEN 的，37signals 的这个动作或许是个积极的信号。2007 年也是个"虚拟化"年，相信随着虚拟化的技术成熟，开源力量的壮大，会有更多的公司收益于 XEN 虚拟化架构.
--EOF--
到了年底了，要预防安全事故，数据泄漏更要预防。CSO 杂志列举了 2007 年的 10 大数据泄漏事件。这里有一份比较全的数据泄漏列表。我觉得这个 美农业部数据库漏洞泄漏十五万人资料 其实也很有实力入选年度 10 大，但不知为何没入 CSO 杂志作者法眼。
原以为这些事件都和什么黑客入侵有关的，真实情况倒是大相径庭：有好几个是着了 “社会工程学” 的道儿：光是硬盘、笔记本被盗就有好几个。金庸老先生说了，"重剑无锋，大巧不工"；小平说了，能拿到数据的黑客就是好黑客。光盯着软件的漏洞下手，还不如奔着人下手容易(比如电影《防火墙》里描述的那样)。比如企业内部网络安全固若金汤，那可以盯着他的备份磁盘磁带下手嘛，要不盯着他出差的总裁、CTO 啥的，在机场、火车站偷丫的。所以，如果要黑某个公司的网络，还不如扮作捡垃圾的，每天检查一下这个公司的废纸。扯远了...
DBA 们，一起来评选一下咱国内的 10 大数据泄漏事件吧? 不过，我好像一个都没听说过，虽说，好事不出门，坏事传千里，可谁让咱报喜不报忧呢。
--EOF--
话说虽然快到年底了,可公司的某个项目(不妨叫做 A 项目)正进展的如火如荼. 该项目意义非凡,工程师连续疲劳作战, 自是压力不小. 项目组成员青轩同学有感于此, 填词一首,说是要调节一下气氛:
长相思 --记 A 项目有感 争一声，吵一声，慷慨激昂闹市中，荆棘已随风。
茶已冷，杯亦空，专注凝神梦不成，皓月挂三更。
看到邮件后,不少人一边笑,一边赞叹. 妙的是, 另一位才子周瑜也很雅,立刻回邮件填词和之:
短相逢 --感长相思-A项目有感 夜重重，意浓浓，苦思冥想情已融，相知镖局中。 日相逢，夜相逢，会友对面难见容，翩然已过冬。
按: 青轩和周瑜是内部的花名. 而"会友" "镖局" 则是公司某个会议室,该项目组封闭开发所在地.
虽然从格律的角度上看,可能不那么严格. 但是信笔写出来的东西足见"有才". 谁说工程师整天写代码没情调? 那是你没看到有趣的工程师, 我们这里这帮家伙一旦搞笑起来也不得了的.
有个同事的评论也很有意思: 厨师不看菜谱看兵书已经让很人吃惊了，谁能想到技术工程师居然写起诗了.... 就在写这篇 Blog 的时候, 还有好几个同事继续填词和之呢...
最后说一下,这个有意思的团队现在求贤若渴. 钱多人少速来, 有兴趣的朋友不妨给我邮件.
--EOF--
在 ITPub 论坛上，最近有朋友发起了一个"请列出你在从事DBA生涯中,最难以忘怀的一次误操作"话题讨论，如果有足够的耐心看下去的话，会发现很多误操作都是类似的，最上镜的就是这个操作系统级别的 "rm -f" / "rm -rf" 了。
在那本著名的 Unix 痛恨者手册 上，rm 问题也作为一个罪状而提出。的确，Unix/Linux 的这个 rm 的 -f 参数是系统管理员（SA)乃至数据库管理员(DBA)最容易引发系统灾难的导火索。
如何避免这样的灾难发生呢?
如果一个人能不犯任何误操作就好了。但这是不可能的。我相信肯定有很多 DBA 或 SA 到现在也没烦过这样的错误，但不要忘了墨菲定律的诅咒。
一种比较理想的是如果编译源代码的时候把这个 -f 选项去掉，肯定能让不少人少犯错误。不过搜索了整个网络，好像还真没有具体如何操作的。Sun 的 Solaris 10 对 rm 作了一点改进处理，"rm -rf /" 是不允许的。可惜的是 "rm -rf *"类似的操作是没限制的。另外，对于其他系统也不可用。或许，将来 GNU/Linux 能有改进。
第二个方式是在 Profile 层次上设置命令别名( alias ).
alias rm="rm -i"
第三个方法是使用替代命令。如用一个 del 命令来替代 rm. 这个就要挑战用户的使用习惯了。真的会始终用替代命令麽? 这个方式需要注意的是，无论如何不要真的把 rm 命令挪走(比如物理的 rename 名字)，如果这样，是很糟糕的策略。
也有不少人直接把 rm 的权限修改，比如只允许 root 用户而不允许普通用户执行命令。这在调用一些脚本或者编译文件的时候，很容易引来很多麻烦。
任何一种策略，如果要扩大应用到一个团队的话，还需要考虑使用习惯对其他成员带来的影响。毕竟，"不爽"也会让很多人更容易犯错。
最后，友情提示，有的人经常通过层层跳板 Login 到主机上，可能会因为忘记了"身在何处" 而犯错误，最管用的方式是设置一下 PS1 环境变量。比如我在 Dreamhost 上用这样的：
PS1="\n\e[1;37m[\e[m\e[1;32m\u\e[m\e[1;33m@\e[m\e[1;35m\h\e[m \e[4m\`pwd\`\e[m\e[1;37m]\e[m\e[1;36m\n\e[m\\$ "
--EOF--
微软员工 Jeff Alexander 在 Blog 上写了一篇 Microsoft.com: What's the story? 报料了 Microsoft.com 站点的一些技术架构信息。不料，这篇文章以迅雷不及掩耳盗铃之势被删除了。还好，Google 以迅雷不及掩耳盗铃之势做了快照。
这篇文章有的地方已经做了介绍，题为微软官网Microsoft.com的一些安全防护数据。但还是漏掉了一些信息。
1) 微软的运营团队 Blog。毕竟是官方的运行团队，在 Blog 上介绍了不少经验，非常值得借鉴。
2) HBI 是啥? 才疏学浅，搜索了一下才知道是：High Business Impact 的缩写。很奇怪，很多人看了那片文章而没有对此有疑问，或许大家都已经知道了。我火星。
3）对待杀毒工具( AV，此 AV 非彼 AV，不知道上面翻译的人为啥没提)的态度。众所周知，对于 Windows 服务器的维护来说，病毒问题会让很多人很头疼。微软运营团队的是态度是：只要有可能，还是会进行杀毒的。
另外，我比较好奇的是微软用什么做 Log 解析。Linux + Perl 这一套东西估计他们是不会用的。
最后，我把英文的快照扔到本站临时目录上了，尽可去一窥全豹[请"另存为"，然后 IE 观看]。
--EOF--
TechCrunch 前两天报道说 Flickr 针对 Pro 用户新增了一项统计功能。今天有看到 Flickr 的 DBA Dathan Pattishall 描述了一下这个统计功能的实现。
Flickr 统计功能的基本技术信息：
Dathan 提到这是他最耗时的一个项目(似乎有点怨言呀)。因为是实时统计，并且还要不影响整体页面响应速度，所以整个项目非常复杂。一旦 DB 设计搞定后，大部分时间都花在如何创建分布锁上了。
其实就我个人而言，真的不觉得这个功能有什么必要(尤其还是实时统计)。这或许是过度设计的一个例子。Flickr 在被 Yahoo！收购之后，这段时间倒是有点颓势。
说起 Dathan 这老兄，在 MySQL 技术圈子算是大名鼎鼎了。曾先后在 Friendfinder、Friendster 做 DBA，并获得国 05、06 两年的 "MySQL Application of the Year Award“。(看他 Blog 的活跃劲儿，估计今年也差不多。)
这老兄加盟了 Flickr 后，一个礼拜解决了 40％ 左右的性能问题。从他的简历来看，Flickr 目前每日 DB 的事务超过 10亿，MySQL 运行在 16G 内存、AMD CPU 服务器上，存储采用本地硬盘而没有用 SAN。数据库采用联邦架构，能做到线性扩展，为公司节省成本达 40 万美元(占40%，从而估计 DB 相关硬件成本为 60万美元).
推荐国内每个 Web 2.0 公司的 DBA 持续关注 Dathan 的 Blog，当然，可能大家都已经一直在看了。
--EOF--
下次要用多于一个晚上的时间来设计编程语言
Second Life CTO Cory Ondrejka 离职公开信中的话。他只用一个晚上设计了 LSL。
在中国，年龄是决定升迁的重要因素
--李银河。出处《中国精英的黑发情结》
我想没有一个厨子会将自己的菜刀上雕花吧
--网友 Grace 论 折腾 Linux 图形环境。
工作应当体现人的社会价值，如机会、社交、认同以及个人满足，而非仅仅反映成本、效率一类的商业价值
--杰克•贝蒂对德鲁克的解释，杰克曾为德鲁克作传记。
现在，我已经放弃了改变这种行为的想法，他们必须得回邮件，因为快速反应很重要
--Google CEO 施密特在加入谷歌不久，发现在讲话时，有一些员工在用笔记本回复邮件，这令他沮丧。但现在他彻底改变了看法。
每个礼拜，如果窝在家里，基本上能看完一两本书(总算没有完全无所事事)。本周看了 《德川家康》 的第一部《乱世孤主》，作者山冈庄八。对于日本这个弹丸之地的历史，除了近代对中国带来的苦难之外，仅有的一点感觉也就是"大名"、"幕府"、"明治维新"，这还是高中历史老师给的，据说有的游戏爱好者对于日本历史蛮熟悉的，这倒也算是文化侵略的一部分吧。
这部书挂着"柏杨策划"的名头，这老头说"中国有两部书的影响力可以和《德川家康》相比，一是《资治通鉴》，一是《三国演义》"，可见这书绝对是通俗小说。相比欧美文学的翻译，这本其实翻译质量还算不错，只是有些日文语境要适应一下。
因为不熟悉历史背景，刚开始看起来非常的累。比较有意思的一点是，书中很强的厌战意味。查了一下，这本书的写作时期刚好是二战后。因为是在报纸上连载，写作日期长达 17 年。这和金庸的小说的协作历程有些类似，只是金庸连载小说是为了救活一家报纸，山冈庄八意在激励日本国民。二者在各自国家文坛地位倒是相似的。
或许这部书能让我更加了解日本。中国有战国时代，日本也有，想想也挺有意思，也就那么大点的地方挤着一大堆诸侯，不往死里斗才怪呢，越狭促，越激烈。
据传整部书 13 册之多：
出版社不知道何年何月能出齐，自己不知道什么事后能看完。暂且做个记号吧。
--EOF--
Amazon 真是酷到家了。在 S3 和 EC2 之后又搞出来一个 SimpleDB™ 。Amazon 一手构造的计算环境中现在又加上了数据库，真是很有想象力的项目。
在 Web Service 上，Amazon 可以说是身体力行，领跑多年。S3 解决海量数据(非结构化)托管问题(虽然当下也是赔本赚吆喝)，EC2 解决企业计算问题，SimpleDB™ 则针对结构化数据查询的解决方案，目前已经能够提供数据库的一些核心功能。对用户来说，你不再需要针对数据库的复杂的维护工作，也就是可以不用数据库管理员( DBA ) 了 。当然，DBA 也不用担心，这个工种不会消失，SimpleDB™ 针对的买方是那些只需用简单的关系型数据的 Web 项目，传统的 RDBMS 功能复杂，但是很多小项目其实只是用到一些核心的功能而已，如大家常说的增、删、改、查，这或许也是帕累托法则的运用吧。
RDBMS 当然不会消亡，SimpleDB™ 是 RDBMS 的竞争对手，也是 RDBMS 的一个补充(我非常奇怪为什么不叫做 WebDB，嘿)。从这一点上说，SimpleDB™ 还是开启了一片蓝海，只是海水比较深，没有足够技术船也过不去。
--EOF--
BTW: 虽然这个消息已经被很多人写了，我还是想写一下，毕竟这也是关于 DB 的事情
Updated: 小道消息，”SimpleDB stuff is Erlang on top BerkleyDB“，如果这么说，或许 Oracle 偷着乐呢
到了年末，招人。支付宝(Alipay.com)和阿里妈妈(Alimama.com)都在招聘 DBA。公司在高速发展，个人也会有足够的发展空间，正所谓：钱多、人少、速来。
我们这里的 DBA 有两个发展方向：产品 DBA 与开发 DBA 。产品 DBA 负责维护线上生产环境，开发 DBA 面向开发人员，控制应用程序 DB 质量。
至于职位要求，以前的这份似乎已经不太适合。我暂时重定义了一下非官方的需求。
产品 DBA 要求:
开发 DBA 要求:
另外，阿里妈妈招聘系统管理员(SA)。
DBA 朋友们，如果你有意在杭州或者上海发展，那么不妨给我发一份简历。我的邮件和Gtalk ：[email protected] 。如果你在网络上有 Blog 或者是技术文章能体现您的功底，那么，把相关信息告诉我，如果您在互联网上很低调，那么简历还是要多写点内容上去，因为起码要能打动 HR。千万不要给我类似这样的简历。
招聘截止到明年第一季度。怎么也要给留出来拿年度奖金的机会吧?
一起来改写互联网的历史。此时此刻，非你莫属！If Not You, Then Who ? If Not Now, Then When?
--EOF--
Yahoo! 发布了一个新的小工具: Yahoo! Shortcuts。该工具旨在加强 Blog 文本内容交互性，似乎只是 Y!Q 的功能延伸而已。目前只有一个针对 WordPress 的插件，对于其他 Blog 发布平台还没有插件推出。看着 WordPress 得到越来越多的支持，我这个 MT 的老用户到真的想转换阵营了。
同样是作为互联网巨头，Yahoo! 的产品发展策略还是比较怪异的。我首先不太理解为什么这么个东西会让雅虎启动这样的二级域名：http://shortcuts.yahoo.com ；另外一个不理解的地方是 Yahoo！ 收购了 MyBlogLog 之后就没什么进一步动作，我的言外之意是 Yahoo! Shortcuts 和 MyBlogLog 的某些功能其实是有些重叠的。
病急乱投医，不是很妙。大块头没智慧，谁都有晕的时候。
--EOF--
尽管手头有重要的事儿，可电影时间要到了，还是被老婆催促出门。看完电影，观众退场，女观众的都在问男观众的，”好看吗?" "挺好!"
”外人乱我兄弟者，必杀之！兄弟杀我兄弟者，必杀之“。这句话从现在开始，有流行的趋势。另一个可能是导演陈可辛一下子取代吴宇森成了"兄弟片"的招牌。
如果说片子有什么缺陷，只是觉得结尾的一段有些冗长。姜午阳反复近身出刀，杀也杀不死，其实是走了老套。
导演真的拍出了大片的感觉。李连杰表演很有突破，没准凭这个片子拿个影帝呢; 刘德华扮演的赵二虎很男人; 金城武角色讨巧; 博客老徐呢, 不评价了，每部片子总要有个女主角不是? 这次的花瓶是粗磁的。
对这部电影给个五星吧，投了一大把钱，也没玩弄观众的智商，再这么挑剔也不好的。
--EOF--
马云财散人聚的能力不比老牛差
--蒙牛董事长牛根生在阿里巴巴B2B上市满月庆功酒会上的致辞
你跟人家争，人家就不用你了...到现在，位置在这里了，你不用争，人家也会给你
--王宝强的访谈 。《士兵突击》之后没人叫他傻根了，都叫他许三多了。
当你听到无数的指责、批评、甚至是谩骂时，不要沮丧，至少人们还愿意评论你，这总比谁都不理咱要强。
iPod设计师乔纳森·艾维 来源
如果只是以上市为目的的话，迅雷可以在任何时间、任何地点上市
--迅雷CEO 邹胜龙访谈
我忽然觉得我以前所做的博客网、互联网实验室都只是热身运动，现在义乌全球网才是我的事业
--方兴东 (这句话一说，估计有几家 VC 很伤心)
总裁我是山西人，未来世界是3C (山西的谐音，3C指电脑Computer、通讯Communication、消费性数码电子Consumer-electronics)。
--郭台铭 （来源)
我只是一个开发人员而已。如果我们俩在工作场合邂逅，他知道我叫什么名字
“MS-DOS之父”蒂姆·帕特森(Tim Paterson) 访谈，提及盖茨
作为 DBA，多多少少要关注点儿关于主机到存储这段链路上 IO 的可靠性问题，Multipath I/O(MPIO) 是需要要了解一下的。业界 MPIO 相关的软件不下几十种，但商业软件居多，开源的似乎只有 Device-Mapper，这也是 Linux Kernel 支持的多路径 IO 软件解决方案。
Redhat 应该是从 RHEL4 U2 开始正式增加的对 Device Multipath IO (MPIO) 的支持。SuSE Linux 则是在 SLES9.2 以后就提供支持了，谁先谁后我还真的不知道，不过SuSE 在这方面还真是一直比较激进，或许这也反映了追赶者的一些急躁心态。
关于如何设置 DM 可以参考 RedHat 站点上的一篇 FAQ：How do I setup device-mapper multipathing in Red Hat Enterprise Linux 4?。对于 RHEL 5 ，有一本 Using Device-Mapper Multipath 手册。另外，这里有篇中文的测试，步骤比较详细。
有些存储厂商在 Linux 上没有自己专有的多路径工具，如果需要类似的功能一般是推荐用 DM，但是我对负载均衡算法还有些持保留意见。 IO 路径选择器只有默认的 round-robin 。在负载均衡配置下，似乎这东西每个路径 在 1000 个 IO 之上就会重新选择路径(这个地方我不确定，谁来澄清一下?)。没有最小 IO 队列算法和最小服务时间等算法可供选择。
涉及到的 Oracle 支持情况: Oracle ASM 支持 DM 映射出来的设备.
--EOF--
这几天用了阿里旺旺(淘宝版)的最新测试版，给我了一点惊喜："最近联系人"作为一个 Tab 单独列出来了，Tab 就叫做”最近联系"。这个变化和 Skype 的 "History" 功能如出一辙，而过去这个功能是作为联系人中的一个“组”来实现的，仍不够方便。Windows Live Messenger(WLM) 和 Gtalk 都还没有这个功能。
之所以说这个功能给了我一个惊喜，是因为每天使用阿里旺旺的过程中，我需要经常去"定位"联系人。而"最近联系"中的人几乎也是每天和我 IM 比较多的联系人，方便了许多。当然，这只是解决了我的一小部分问题，对于“快速定位联系人“ 实际上还不如 Windows Live Messenger 方便。WLM 的用户应该都比较喜欢该工具的 "Find c contact or number" 的对话框，输入简单的几个特征字母，即可大致过滤出想要通信的联系人 ID ,对于有大量联系人的用户来说，这是非常关键的功能。
我们常说帕累托法则，"重要的少数"到底分在什么地方呢? 对我这样的用户来来说，一个 IM ，如果能够避免每日无效的重复就是那个 20%，如果把这个 20% 的问题解决，就能起到 80% 的功效。再比如，Gtalk 在 保存聊天记录这个功能上，就是杀手级别的功能，所有 IM 中，查找聊天记录最方便(当然，Gtalk 其他功能还欠缺得多)。
阿里旺旺(淘宝版)面对的买卖家双方，卖家肯定更为重要一些。而卖家的联系人又都可能是比较随机的，这个时候快速定位联系人肯定是需要迫切解决的一个问题。对于买家来说，更多依赖的功能肯定是查找聊天记录，当然该功能卖家也同样会有比较高的使用频率。如这两个角度下手，事半功倍矣。
一个好的 IM 工具最好也能够一定程度上提升效率，或许，这应该成为设计原则之一。
--EOF--
插播一则广告：来自 ITpub 的朋友请帮忙投一票。
拉票这事情我还真的干得不多，第一次搞，脸皮虽然厚也有些发烧，因为已经有DBA在说“熙熙攘攘"了。
有些 Linux 数据库服务器用的比较低端的存储，因为业务的变化，有时候需要新增一些 LUN。Linux 服务器添加 LUN 后必须要重启动 ? 有的时候存储厂商工程师也这么说，不过这似乎是一个一直被误解的信息。
从专攻存储的同事那里得知利用 QLogic FC HBA LUN Scan Utility 这个脚本即可无需重启动系统而识别新添加的 LUN。也无需对 QLogic FC driver 的重新 Load。
场景：Linux Server + QLogic 的 HBA 卡 。以 QLogic 的 Qla2340 HBA 卡为例。下载该脚本(顺便说一下，该页面的 QLogic FC HBA Information Utility 也比较有用)。然后看一下脚本说明文件。
用法最简单只需要运行：
# ./ql-dynamic-tgt-lun-disc.sh
脚本会提示在没有活动 IO 的情况下运行。其实问题不大的了。 之后确认 OS 识别到新设备:
# fdisk -l
如果系统中有 PowerPath ,还需要运行：
# powermt config
OK。多少提高了一点系统可用性，你可以不用向老板申请停机维护了。
附：另外一篇参考文档.
--EOF--
今天在公司给同事做了一次关于时间管理的培训。
昨天又熬了一个通宵，早晨8点到家休息，下午 3 点多到公司，杂事还不少，忙活，培训前半个小时我才坐下来，还没等重新看一下培训文档以便组织语言就不得不匆匆上阵了。
培训内容大体上是 "GTD 方法" + "Above & Beyond" + "Web 2.0 方面信息分享的相关工具" 这几个部分。第一部分是听的人头晕，做讲座的我也有些没词儿，效果真是糟糕。加上一天没吃饭，有一阵儿还一阵眩晕。说了不少车轱辘话。自己感觉只有最后一小部分内容还算凑合。堪堪在预定的一个半小时完成整个 PPT 的演示，没有太耽误大家下班吃饭。看培训完毕后发过来的调查表，好几个同事都认为互动做的不好。
第一次做关于时间管理的讲座，很有些摸不到用户需求的感觉(如果说纯粹技术的内容，或许还能多唠叨几句)。另外一个问题也是这东西相对比较"空"，很多人帕"浪费时间"就不来听了，很多人认为没啥用途.....
一点感想：成为一个好的演讲者可真不是容易的事情。平时和同事、朋友随便聊天的时候可能还算健谈，但是要在一个多小时内能够持续的做清晰表达，不说车轱辘话，且不带进来一堆口头语，对节奏又能有一定的控制，可真是比较难的。而这些，恐怕也只是对一个讲师最基本的要求吧。
这个讲座在部门内应该是"空前"(之前没人做这个题目)的，恐怕也是绝后的了--没准因为效果差，以后不让做了...哈
--EOF--
使用 iPhone 有一段时间了。基本上处于初级用户的阶段。有一天同事拿过我的 iPhone 一看，发现我几乎没安装额外的软件，对我大为鄙视。虽然还是初级阶段，但是也能有点使用体验。胡聊一下。
对于待机时间，我基本上没那么多时间 Wi-Fi ，不看视频，不听 Mp3 ，就这样，最多也就是 3 天的待机时间。如果上述几种应用玩的比较多，可能 1 天都撑不住，尤其是 Wi-Fi。
输入法我用的是 NativeCN ， 不太好用，最烦的是，字库似乎缺字。可能是我的输入法不太灵光，短信发送也不是非常方便，虚拟键盘经常按错，NativeCN 不能自动联想(倒是能记住用过的词汇，可惜多数时候没有用)，还好，我不是短信狂。我对这个 SyPhone 倒是挺感兴趣的，能够备份 SMS 消息，可惜的是目前只支持 Mac。
对我来说，iPhone 的一个最大不便之处就是电话簿的查找，如果联系人比较多，屏幕需要滚动好久才能找到。虽然右边有一个快捷指示栏，但如果某个子目下联系人比较多，查找还是比较痛苦的事情。
累了，凌晨还有项目发布，有空再继续唠叨。
--EOF--
Updated: 升级到了 NativeCN 2.4 ，输入好了很多.
这个标题其实是说我今天早晨路上的感受。
忙活完了，八点钟，下楼回家。因为从没有那么早上班(当然我这是下班)，万塘路和华星路的十字路口，红绿灯一个切换的功夫，大约几百辆自行车一起冲过来，我刚好在路中间，晕，那几十秒钟，我好像刘姥姥进了大观园。我一直以为这条路上的人很少的。同在一个城市中，谁知道谁的生活呢?
还好，这一天总算要过去了，真他妈操蛋的一天。
--EOF--
自从 FeedBurner 被阻尼了之后，离线 RSS 阅读工具就不能用了。基本上只用在线的，Google Reader 。可是仍然有很多 FeedBurner 烧录的 Feed 地址需要订阅，比如很多英文 Blogger 的 RSS。还有就是国内很多 Blogger 仍然异常"顽固"，仍然不换国产 RSS 阅读工具，最糟糕的是很多用户用了 "点击统计" （Item views） 的功能，阅读器里看到的不是源 URL 地址，而是 FeedBurner 烧录地址跳转，偏偏有的帖子还是没有全文输出或者格式不好，有的时候要看原文章不得不用代理，很影响我个人阅读体验。
对于 Firefox ，我用了一个可能比较土的解决办法。首先是安装 Vidalia （cross-platform controller GUI for Tor，至于 Tor 是干啥的，你可以问 Google)， 借着安装 Firefox 插件 Torbutton，安装这一个后，基本上你可以访问你感兴趣的那些被阻尼的技术文章或者站点了。但是这东西一是总要切换来切换去的(不切换的话又会影响正常页面的访问速度)，所以最好还是再安装一个插件 FoxProxy 。安装完重新启动后会问你具体的设置，点击几次 Yes 之后有个定制页面。如下图设置即可：
然后重启动 Firefox ，在 Google Reader 里面点击那些 FeedBurner 转发的 URL 就会自动处理了。在 Twitter 上有朋友推荐 Gladder，我没有测试，谁用过不妨交流一下。
另外，建议 FeedBurner 用户关掉那个 "点击统计" （Item views） 功能。如下图所示:
--EOF--
一晚失眠，好不容易要睡着，报警短信狂响，爬起来，登录上去，检查半天，暂时不能定位到问题。兄弟们住的都比较远，干脆我自己跑到公司吧...
这半年来，我还真的很少这么早走在马路上，街上好像刚洒过水，真冷。公司楼下的 KTV 那边走过来一群人，估计刚唱完歌，年轻人真有精力...
到公司仔细检查了一下，还算顺利。定位到问题，基本上能控制住影响。又等了一会儿，厂商工程师赶到(大家都不容易)，对坏的模块重新换了一个端口。我这头检查主机，状态也正常了，才算放下心来。
这就回家睡觉去，这日子过的!
--EOF--
采取 Windows 技术路线的 Web 2.0 站点并不多，除了 MySpace ，另外就是这个 PlentyOfFish。这个站点提供 "Online Dating” 服务。一个令人津津乐道的、惊人的数据是这个只有一个人(创建人Markus Frind）的站点价值 10 亿，估计要让很多人眼热，更何况 Markus Frind 每天只用两个小时打理网站--可操作性很强嘛。
之所以选择 Windows .NET 的技术路线是因为 Markus Frind 不懂 LAMP 那一套东西，会啥用啥。就这样，也能支撑 超过 3000 万的日点击率(从这个数字也能看出来人类对自然天性的渴望是多迫切)。Todd Hoff 收集了很多关于 PlentyOfFish 架构的细节。记录一下感兴趣的部分。
PlentyOfFish 比较特殊的一个地方是 几乎不需要 Cache，因为数据变化过快，很快就过期。我不知道这是因为 ASP.NET 的特点带来的架构特点，还是业务就是这个样子的。至于图片，则是通过 CDN 支撑的。对于动态出站(outbound)的数据进行压缩，这耗费了 30% 的 CPU 能力，但节省了带宽资源。我最近才知道，欧美的带宽开销也不便宜。
微软 Windows 网络负载均衡(Network Load Balancing) 的一个缺陷是不能保持 Session 状态(我没有用过这玩意儿，不能确认)，价格也不便宜，而且复杂；网络负载均衡对 Windows 架构的站点又是必须--IIS 的总连接数是有限制的。PlentyOfFish 用的是 ServerIron (Conf Refer)，ServerIron 使用简单，而且功能比 NLB 更丰富。
一共三台 SQL Server，一台作为主库，另外两台只读数据库支撑查询。数据库性能监控用的是“Windows 任务管理器"。因为 Cache没啥用，所以要花大力气优化 DB。每个页面上调用 DB 次数越少越好，越简单越好，这是常识，不过不是每个人都体会那么深而已。
微软好不容易找到了一个宣传案例，所以在 Channel 9 上有一个 PlentyOfFish 的访谈。
PlentyOfFish 取自天涯何处无芳草(Plenty of fish in the sea)的意思，还挺有文化的。从这一点上看，比国内那些拉皮条的网站好一些。
--EOF--
与国内的 Web 2.0 Startup 技术人员相比，国外技术人员更乐于分享。分享也是一种更好的宣传手段，如果不是看到了这篇 Scaling an early stage startup， 或许我就不会知道这位 Mark Maunder (他还有个中文名字：马孟德) 以及他的 FeedJet。
一般来说，一个刚刚发布的 Web 应用，因为用户量并不多，性能问题可能并不是很明显。可一旦宣传展开，用户增长或许不是线性的而是暴增(从几十个到几万个，相比之下怎不是暴增?)，这时候如果遇到性能问题，毫无疑问会影响初期用户的信任。
Maunder 文档中列举了一个扩展过程，相信这些例子也是他实际遇到的。毕竟 Startup 都是一两个人打通关，不可能所有技术都面面俱到的精通。下面记录一点。
数据库服务器的参数配置问题：导致 MySQL 消耗了大量资源。Apache Keepalive 的设置为不合理，修改为 off。我想这个前提应该还是要选择自己最擅长的技术路线。如果错误的选择另一条不熟悉的技术路线，那么遇到技术时解决问题的速度怕是更让用户恼火。对于 Apache 还应该知道 Httpd.Worker 比 Prefork 消耗更多内存 (httperf 来进行 Benchmark) ，内存也是蛮贵的。
尽可能的利用数据库的 Cache，利用其他 Cache 工具，如 MemCacheD，来减轻对磁盘的 IO 压力。为了节省成本，很多站点都是用的低速大容量的磁盘，所以，充分利用 Cache 是一个网站成功的必然条件。这样的软件BerkeleyDB 的最高事务处理记录是 90000 事务/秒。
说白了，也是为了减轻磁盘的压力。现在很多 Web 2.0 站点都把图片放到 Amazon S3 上，省心了不少。当然，国内还没这样的服务。
现在连那些大站点都在阻止图片被第三方引用，小站点更要提防被大站引用，很容易耗光网站的容量。另外一个要注意的是网络爬虫的频率。
在线观看这篇 Scaling an early stage startup。顺便说一下，最近在 Scribd 上看到了不少有意思的文档。
--EOF--
