提起 MapReduce ，第一直觉会想起 Google 的 BigTable + MapReduce 经典组合。MapReduce 已经是大规模集群计算"杀人灭口、居家旅行"的必备之物了。而 SQL+ MapReduce 无疑是充满想象力的，意味着 BigTable 可以用 DB 来替代，DBA 们感觉有戏了。
Greenplum 设计初衷是面向大规模数据分析的，能轻松扩展到 Petabyte 级别，通过 Greenplum 的并行数据流引擎能够让程序员玩 MapReduce， DBA 跑 SQL ，可谓两全其美。
类似的思路已经给数据仓库市场带来了一场革命，Greenplum 的间接竞争对手其实应该是 Hadoop 。Teradata 好日子不多了。
--EOF--
Updated: Aster 也是和 Greenplumn 相类似的架构:
有趣的是，MySpace 采用了 Aster ：
数据库巨头 Oracle 一向不怎么涉足硬件领域，但这并不等于没有硬件方面的野心(过去折腾过几次都失败了)。这次在 Oracle Open World 上一下子宣布了两款 Exadata 系列的存储产品。一个是 Oracle Exadata Storage Server ，另外一个叫做 HP Oracle Database Machine 。
该产品基本上可以看成是山寨版的存储集群。只是山寨主人财大气粗，所以比较唬人。
如上图，是基于所谓的 Cell 的，每个 Cell 就是一个存储模块，乍看上去好像 HP 的 MSA 系列的东西 ，考虑到这东西能扩展能大柜子，又很像 HP 的 EVA 产品的变形(早就听说 EVA 准备推出 Cluster 的形式)，不过接下来又看到每个 Cell 有自己的 CPU、内存、NIC，莫非就是个 PC ? 等我下载了一份 Data Sheet 看了一下，居然就是个 PC 服务器 ......
从上图大致能看出来，Oracle 主要的还是想卖软件，企业管理器、念念不忘的 Automatic Storage Management(ASM)，还有山寨版 RHEL --OEL 也在这个框架内。
iDB - the Intelligent Database protocol. 这是这套系统中的一个亮点。iDB 在数据库核心层实现，直接映射操作到存储，减小不必要的开销。如果 iDB 真的能有效提升 IO 能力，那这个产品还是值得一用的。每个 Cell 是有计算能力的，实际上相当于 DB 把 SQL 扔给 Cell， Cell 返回结果给 DB 。iDB 能够运行在 InfiniBand 之上。
Oracle 的 RAC 集群是 "Share Storage" 的，DB 节点间的高速通信其实是很容易撞上天花板。如果要提升集群能力，只靠 DB 本身的能力其实不大现实。这个 Exadata 的设计思路就是希翼通过硬件集群的能力来扩大 Oracle 本身的 I/O 能力，而 InfiniBand 交换机成了核心的组件。
实际上，InfiniBand 交换机的数量会是问题，只用一个，可靠性不高，用两个，成本又上去了。这个无疑会让用户左右摇摆。
相当于一个打包好了的产品，预装了 Oracle 企业版 Linux 与 Oracle DB 11g 软件，面向数据仓库环境。假想敌是 Teradata ?
流水帐写了这么多，最后我个人认为该产品是否能被市场接受还要看定价，如果足够便宜，那么会有用户拿来做中低端的应用，如果 Oracle 必须要把内置的软件卖出价钱来，那恐怕竞争力并不是很强。
这并非一个会让人多么激动的产品。
--EOF--
附加：价格列表
对 Outlook 的厌烦由来已久了。我以前在 Twitter 上说，平均一天 Outlook 会收到几百封邮件，管理、查找、定制规则、备份都是非常费神的事儿。再说 Outlook 软件本身的稳定性也不太好，经常处于假死状态，关闭打开几次才能使用。
每天早晨到公司后第一件事情是打开 Outlook，先忍受龟速邮件接收(Pop3 邮件的瓶颈)，然后大约要两拨邮件风暴，接着才能工作。
自从看了《简单法则》之后，越来越觉得没必要把事情搞得那么复杂。直接用 Gmail 代替 Outlook 好了。有什么好担心的? 自己绝大部分时间都可以上网，邮件也无需考虑本地占用本地空间备份；会议通知? 直接扔到 Google 日历上去就成；如果还有不放心的，花 20 美元买 10G 的Gmail 空间也不算贵，到时候 Google 总不至于随便删除用户帐户了吧?
说了就做，简单设置了一下，已经比较好用了，尤其喜欢"等宽字体显示(Show in fixed width font"的功能。一天没打开 Outlook ，坚持，坚持，Ok，好像到现在也没到世界末日。
最后，欣闻 Outlook 荣获 "给用户造成伤害7大技术" 之一的称号，我更觉得这事儿值得一做。
--EOF--
现在存在的问题（基本上都是用户习惯的问题)：
本文首发在支付宝官方Blog：支付志
自从支付宝（中国）网络技术有限公司宣布支付宝对 Firefox 的支持之后，很多 Firefox 忠实用户已经下载并试用了该安全控件。这里分享几则使用过程中的常见问题。
Q: 到哪里下载 支付宝安全控件 for Firefox ?
A: 您可以到 Firefox 官方附加组件站点 下载该插件。URI 地址在：
https://addons.mozilla.org/zh-CN/firefox/addon/6707
这是个可信地址(您需要首先在该站点上注册一个用户)。另外建议请不要安装其他未经过验证的地址下载的支付宝安全控件。
Q: 安装了支付宝安全控件(AliPay Security Control)后，为何无法看到密码输入框?
A:: 目前的支付宝安全控件 for Firefox 还不支持数字证书。所以如果您是支付宝证书用户，需要在 IE 浏览器下登录到支付宝，然后选择"数字证书" --"注销证书"。这样会降低保护级别。参考这篇《四步打造你的金牌安全支付宝》。
如果上述方法不管用，可能是插件冲突的问题，请您拨冗给我们留言，列一下您用的 Firefox 插件列表。不胜感谢!
Q: 是否支持 Linux 操作系统下的 Firefox ?
A:: 很抱歉，暂时还不提供支持。不过已经在开发测试过程中。给我们一点时间，我们给您惊喜！
问(Q): 我按照第一条Q&A 的提示做了，可还是不能用。
答(A): 请检查您是否使用了 NoScript 插件，如果是尝试禁用插件看一下。
BTW: 关于支付宝在 Vista 上的常见问题，参见 Vista 下支付宝控件、证书的相关使用问题。
建议您请收藏本文地址，我将持续更新......
《简单法则》这本书只有 100 多页，一个睡前的阅读时间即可看完。
法则1 是：精简(Reduce) ，原文翻译做"减少"，有些山寨的感觉，当然作者肯定经过斟酌的，我还是觉得"精简"比较好。如无必要，勿增实体。然后的指导方法是：SHE，这不是指那个流行偶像团体，而是指缩小(SHRINK)、隐藏(HIDE)、赋加(EMBODY)。
看书的过程中，这是第一处让我产生很深印象的地方。用 Twitter 改版后的界面来说说 "隐藏":
注意右上角的处理部分。鼠标移动上去才会显示可操作内容(这一点国内的几个模仿者还没有跟进呢)。再去看看 Facebook ，对这一点也有很好的提现。当然，类似的设计不是对所有 Web 站点都适用，必须要考虑用户群的 Web 使用经验。Twitter 是个很容易让人产生信息过载的地方。不过设计者在很多地方都体现了《简单法则》一书中的观点，大道至简，殊途同归吧。
BTW: Twitter 界面上的消息发布时间用斜体字我觉得很不协调。
这一点和很多时间管理的思想是相近的，大部分看我网志的人都知道 GTD 的吧? 只是执行起来的人很少，执行好的人也不多。这一原则相当再一次提醒我们。
为什么在网上会出现 Paypal、支付宝这样的服务? 那是因为人们彼此间的信任程度不够，这样对整个交易的成本也是增加的，事情也自然复杂化。
远离(Away)，我觉得应该把这一条单独提出来。
写到这里，我发现这本书还是很适合做产品设计的朋友看看的，体会一下其中的思想。不要因为实现某些垃圾功能而把产品设计的那么臃肿，那么难用。
--EOF--
这本书也不写书评了，写也写不过小容的这篇《敢问北极熊，路在何方？》，何况小容在信息架构方面已经有比较深入的钻研了。
小容把这本书列为信息架构师必读书之一。我也是因为这个豆列对这本书感兴趣的。之前，什么是信息架构，什么人是信息架构师，还真是不容易搞明白(我曾经接到过的名片中，也没有一个人自称是信息架构师的)。
什么是信息架构呢? 这本书其实也没给一个清晰的定义，似乎有些可意会不可言传的意味。我的理解信息架构做的事情就是组织、梳理总体信息使之达到更可用。如果这样说的话，大一点的面向内容的 Web 站点（比如淘宝）都需要信息架构师的。又比如中大型门户网站，如果缺乏整体的内容梳理、组织，访问用户就不能得到更好的用户信息获取体验，甚至会信息偏差、缺失，对于网站来说，是无形中的损失。
信息架构师，国内有哪家公司有这样的职位么? 应该没有。
这本书也是我认为的 Web 2.0 网站架构不可或缺的图书 之一。当然，CTO 们是最应该看看洗洗脑，问题是，CTO 们都在开会呢，哪有时间看书哇。
附注： 购买《Web 信息架构》请点击。在下一篇，我可能说一下有关时间管理。
--EOF--
如果你是Google日历的用户，请订阅这个支付宝2008校园招聘行程表。
今天晚上和公司招聘团队到浙江大学（玉泉校区）进行招聘。
现在的学生基本都不带纸质的简历了，问了几个同学，都说在网上投递了简历。其实随身带着简历还是有用处的，有句话说得好，"机会只给有准备的人"，多和招聘公司的人聊聊，还是会给自己和招聘公司很大机会的。毕竟校园招聘其实是个误差很大的事情。
有些简历其实没有加任何心思。只是简单的罗列了一些课程和自己的知识背景，如果几百封简历放到一起，如何脱颖而出呢? 我倒是抓了点机会和现场的同学聊了一下。写简历其实是有点讲究的。
和学校里的志愿者聊了一会儿，发现现在的学生其实信息挺闭塞的。工作轻松，赚的钱多，是大多数人的不切实际的梦想。
现场效果不错。有个同学问的问题很中规中矩。现在是笔试时间，估计今天要后半夜回家了。明天是现场面试，所以一大早就要起来准备。招聘是个体力活。
浙大的校园无线网络很好，所以上来写几句。对了，在邵逸夫科技馆里还看到了常书鸿的塑像，注意到常先生卒年是 1994 。
--EOF--
补充一些：
我也是今天晚上才看到的笔试题目。怎么说呢...题目应该是内部收集上来的，主观题部分还是有些......虽然考场内空气不是非常好，留下来参加笔试的同学都挺认真，找工作也不容易。
到了阅卷的时候，发现有的人主观题部分其实已经拿到足够多的分数了，而客观题的回答千奇百怪。到这个部分阅卷评分也只好"主观"一些了。
可能是信息不对称的原因，几乎绝大部分人都是奔着开发工程师去的，而关于系统工程师、安全工程师、UED 的投递者非常少，稍微透漏一下，因为投递者太少，导致这几个岗位竞争一点都不激烈。实际上在支付宝这几个岗位的成长性也都是非常棒的。
尤其是 UED 和前端的一些知识，我相信大多数学校教的东西都是很肤浅的，但是，如果平时能多关注网上的一些东西，考卷上体现出来的东西还是很容易让人眼前一亮。只可惜，今天晚上很少让我看到眼前一亮。
我相信考试只是一个手段，是否能完全体现出所有人的能力? 肯定不能。但是几百号人，怎么能做出有效的筛选? 看简历? 误差会更大。可能考试是唯一的过滤办法了。
以上都只是我的个人看法。
最新的招聘活动更新请参考支付志(支付宝官方网志)
--EOF Again--
此文首发在 InfoQ 中文站。作者：明灵(dragon) , Fenng . Note：要转载的朋友请注意注明这篇文章的第一作者!
这篇文章是dragon 朋友来邮探讨后他做的一个总结。在 DB 中排序还是在 应用程序中排序是个很有趣的话题，dragon 第一份邮件中其实已经总结的很好了，我添加了一点建议而已。现在放上来，与大家共享。这篇文章也投稿到了 InfoQ 中文站 。
A：通常来说，执行效率需要考虑 CPU、内存和硬盘等的负载情况，假定 MYSQL 服务器和 PHP 的服务器都已经按照最适合的方式来配置，那么系统的可伸缩性（Scalability）和用户感知性能（User-perceived Performance）是我们追求的主要目标。在实际运行中，MYSQL 中数据往往以 HASH tables、BTREE 等方式存贮于内存，操作速度很快；同时 INDEX 已经进行了一些预排序；很多应用中，MYSQL 排序是首选。而在应用层（PHP）中排序，也必然在内存中进行，与 MYSQL 相比具有如下优势：
至于执行速度，差异应该不会很大，除非应用设计有问题，造成大量不必要的网络IO。另外，应用层要注意PHP 的 Cache 设置，如果超出会报告内部错误；此时要根据应用做好评估，或者调整Cache。具体选择，将取决于具体的应用。
从网站整体考虑，就必须加入人力和成本的考虑。假如网站规模和负载较小，而人力有限（人数和能力都可能有限），此时在应用层（PHP）做排序要做不少开发和调试工作，耗费时间，得不偿失；不如在 DB 中处理，简单快速。对于大规模的网站，电力、服务器的费用很高，在系统架构上精打细算，可以节约大量的费用，是公司持续发展之必要；此时如果能在应用层(PHP) 进行排序并满足业务需求，尽量在应用层进行。
--EOF--
对于构建 Web 站点，《构建可扩展的 Web 站点》重点并不是讲述 How-To 的 -- 讲述 How-To 的书已经很多了，却很少有图书愿意分一部分篇幅讲述 Why 。所以有的人可能认为"缺少细节"，有的人则读罢大呼过瘾。我一般的建议是，如果你觉得这本书没劲，那就再读一下第二遍。
为什么我推荐这本书? 主要的原因是这本书给出了可扩展站点的必备要素，而书的内容几乎全是作者在 Flickr 站点实战中得来的经验谈，如果您的站点是个发展中的 Web 2.0 站点，你可以认为这本书是个技术"标本"。如果回顾一下我的 Blog 的话，会发现多则关于 Flickr 的技术话题：
当然，这些这些都是皮毛。
如果你正在为你的网站性能问题而苦恼，那么建议直接去读第八章，这一章也是让很多人觉得有价值的章节，因为讲的是"瓶颈"(可见如何解决网站性能瓶颈是个多么普遍的话题啊)。如果严格的来说，这一章的内容并非有多么深入，但对于需要对网站性能瓶颈建立全局概览的朋友来说，足够了。毕竟我们看书不是挑刺，解决自己的问题是首先要考虑的问题。
对我来说，第九章也让我收获良多。第四层负载均衡和第七层负载均衡的差别，什么时候合适用第四层均衡，什么时候用第七层均衡，如何构建一个第七层负载均衡网络... 这些看似都是基础的问题，但实践中是需要仔细平衡的一个事儿。并非想象的那么简单。
如果 Cal Henderson 能有下一部书的写作计划，我倒是希望能看到设计可扩展的 Web 2.0 站点的主题，当然，可能我们看不到了，因为，Flickr 被 Yahoo! 收购后似乎缺失了进取心，谁知道 Cal 会不会跳槽而走呢?
PS: 这也是我认为"Web 2.0 网站架构不可或缺的图书"清单中的一本。
--EOF--
和同事闲聊突然想到的。他 "在Slackware , Arch 与 Ubuntu 之间徘徊...以前一直用 Slackware, 有点洁癖"，我给的建议是"抛弃洁癖"，直接用 Ubuntu 好了。
类似的极致是这样的：用 Mac 笔记本，安装个 Windows ，Windows 上安装一套主题，模拟出苹果的界面 ...
洁癖，或者说是强迫症，会害死人。温瑞安小说中有个人物，叫做"神捕"刘独峰，这个人最后的死因居然是因为自己的洁癖 -- 衣服脏了而丧失战斗力。
其实工作生活中经常遇到类似的场景，非要所有东西都"对了自己心思"后才能把事情做好。比如用电脑就用 Mac ，MP3 就用 iPod ，迷恋某个品牌不能自拔，其实在苹果之外也有很多精彩的东西。又如技术人员对某个编程语言的痴迷，迷 Python 的就鄙视 Ruby ，迷 Ruby 更不屑微软的技术线...
有些洁癖或者说是"偏执"，到了最后往往容易让人忽略了事物的本身目的。比如有些朋友用 Linux 做共作工作用操作系统，把大量的时间用在了"定制"桌面这个事情上，而忽视了他本来是"使用"操作系统这个事情。
作为一个技术人员，口味还是要放开一些，始终迷恋于一个东西，总会营养不良不是? 而一些不会带来实质性提升的洁癖，还是扔掉吧！
--EOF--
闲言碎语，很为偏颇
2e3587f6
对于前端优化技术，我之前根据已经从 14 条增加到 34 条的 Exceptional Performance 做了一份笔记：
这些最佳实践看似没什么艰深的技术含量，而网络上也能看到很多关于网络前端优化的文章，但是实际上我发现能操作、执行下去的网站还是不多，更多的时候，大家把类似的信息当成参考信息而已，看过，丢掉，如此而已。Web 前端优化的时间准则有些其实也算是常识。我曾经听到过某家大型网站的案例：用户反映网站速度慢，进行了多次技术会议，多个方案评估之后，"发现"是图片拖慢了整个网站，于是，大家的意见统一了，建设更多的 CDN ... 可实际上，这个问题或许不需要过多的投入研究，简单的分析一下页面元素比例就知道了。
这本《高性能网站建设指南》的内容以最初的 14 条优化准则写的，精炼简洁(几个小时就能读完)，我觉得已经抓住了前端优化的至少 80% 的内容，加上书中的一些引申内容(尤其是涉及到的 RFC)，如果这些都能做好，那么已经能够解决绝大部分问题了。所以是绝对值得网站运维人员一读。而且，我也认为这是 Web 2.0 网站架构不可或缺的图书 之一。
另外，发现博文视点的这一批 O'Reilly 的图书都是有索引的，很难得。
--EOF--
链接：购买《高性能网站建设指南》
乔布斯擅长的事情，一个是谈判，一个是设计 Apple 机箱(或者是 iPod 外壳)。
记得前段时间有同事开会的时候问大家这个世界最有品位的人是谁? 天，居然说是乔布斯，我宁愿说盖茨，也不愿意说是他。如果选择最苛刻的人到差不多可以是乔布斯，因为苛刻，才能"选择"出比较完美的东西。不要说是他"设计"的。
那么多苹果迷应该明白，你们喜欢的是苹果的产品，而不是乔布斯这个人。 乔布斯头上的更多光芒都是抢来的(他也自诩为海盗)，因为他是苹果的创建人之一，所以他有这个权利。就像古代皇帝喜欢给自己个大将军的称号一样，Jobs 最喜欢干这样的事儿，而且，绝对不会脸红的。当然，这世界太多攫取别人工作成果当成自己的案例。每当看到业界人物厚着脸皮自己介绍"曾主导设计某某产品"，那就让人明白这个家伙除了在这个项目里面"坐顺风车"之外什么都没干。
即使是 Pixar 的成功，也丝毫看不到他在里面究竟起到什么作用，这个时期，他不过是个老板罢了，可一旦那些动画大作成功，镁光灯下的却是乔布斯，那些天才们早都知趣的躲到了一边。
这也是个绝对拧巴的人，多少年都不承认自己的女儿，却把他视为珍宝的项目命名为女儿的名字，Lisa，最后这个注定要失败项目被人视为笑柄。
相比之下，Steve Wozniak 倒是更像一个神，从凡人到神。而 Steve Jobs ，只能是这个商业社会中的一尊偶像。
--EOF--
链接：购买《缔造苹果神话 》 (翻译这本书的人不太懂 IT )
过节了，可能有的朋友都不上网了，在这里还是要对通过 BLOG 认识的朋友们说声：中秋节快乐！
这几天我的 BLOG 因为迁移 Feed 地址导致更新有点问题，建议朋友们还是用 http://www.dbanotes.net/index.xml 来订阅吧。
收集几个 Web 站点的 中秋 Logo，请您欣赏：
支付宝首页的中秋 Logo (其实是个Flash，我做了截图)：
淘宝的中秋 Logo：
雅虎中国的：
其他网站的(三大门户都没有专门制作中秋 Logo )，Google 中国的：
(这里还有个Google 中国历年的中秋Logo)
百度的(这次的似乎有点粗糙，有人说取自"名画"，那大雁也有点太抽象了吧?)：
盛大在线的：
口碑网的：
VeryCD 的：
网易有道：
腾讯搜搜：
此外还看到抓虾(最近一段时间已经停止了开发新功能)也做了一个 Logo，不知道是不是把去年的拿出来用了。
从这个小事情上也能看出来不少网站做事情的态度，和 UED 部门的相关能力。还有哪些有趣的? 大家帮我补充一下?
--EOF--
搜索引擎的行为会对网站架构稳定性有影响么? 肯定的。影响都有哪些呢? 且说，Google 的 Jayant Madhavan 在 VLDB 2008 会议上做了题为 Google's Deep-Web Crawl 的报告。这个报告其实也透漏出了 Google 对一些网站的潜在影响的某个方面。
Deep Web (译为深层网页?) 目前容量大约有多大? 超过100 亿的不重复表单，而且大量都是结构化数据。对搜索引擎用户来说，这部分潜藏的数据是非常有价值的。Deep Web 包括的信息内容：
Google 的解决办法是基于信息模板(informative templates)。其实不难理解，这些模板（似乎也叫查询模板, Query Template）是在 Google 进行了大量的数据分析的基础上得出来，然后通过反馈迭代修正，加上Google 引以自豪的算法啦，渐渐的模板就会很好用了。
绝大多数网站表单后面是要有数据库支撑的。Google 自己计算出来的模板实际上会对应被爬行网站的 DB 查询上来(Google 也是黑箱研究嘛)，如果查询模板不是很匹配，或者是 Google 查询的频率过高，相信会对一个被爬行网站的稳定性带来很大冲击。尤其是针对数据库，一时爆发的大量查询引发的高负载可能会让系统撑不住。
--EOF--
更多的时候，搜索引擎带给一个网站的访问压力甚至大于用户带来的压力，所以，设计的时候也应该尽量采取悲观的方式，不能完全期待 Google 以及其他搜索引擎默认行为都是可以承受的。
又到了校园招聘的时间。支付宝的校园招聘计划也启动了。对支付宝感兴趣的同学可以留意一下招聘行程。
支付宝（Alipay.com）是国内领先的独立第三方支付平台，由阿里巴巴集团创办。公司从2004年建立以来，始终以"信任"作为产品和服务的核心。致力于为中国电子商务提供"简单、安全、快速"的在线支付解决方案。
支付宝提出的建立信任，化繁为简，以技术的创新带动信用体系完善的理念，深得人心。短短三年时间，用户覆盖了整个C2C、B2C、以及B2B领域。截止2008年5月6日，使用支付宝的用户已经超过8000万，支付宝日交易总额超过3.5亿元人民币，日交易笔数超过150万笔。
目前除淘宝和阿里巴巴外，支持使用支付宝交易服务的商家已经超过46万家；涵盖了虚拟游戏、数码通讯、商业服务、机票等行业。这些商家在享受支付宝服务的同时，更是拥有了一个极具潜力的消费市场。
支付宝公司拥有专业化的风险监控系统，拥有与银行同等水平的资金管理团队，拥有国内同行业中一流的技术储备。08年产品技术团队将建立上海研发中心。
支付宝，有着创业团队火一般的激情与斗志！
宽阔的发展通路，活色生香的工作氛围，以及年轻、简单、快乐的人际环境。
杭州 浙江大学 玉泉校区邵逸夫科学馆 9月22日 19:00
杭州 杭州电子科技大学 第7教学楼127多媒体教室 10月16日 18:30
南京 南京大学 南大科技馆报告厅 10月9日 18:30
上海 华东师范大学 一号楼报告厅105 10月21日 18:30
上海 上海大学 第三教学楼5楼演讲厅 10月22日 14:00
成都 四川大学 招生就业办201报告厅 10月9日 18:30
成都 电子科技大学 清水河校区活动中心园厅(新校区) 10月10日 14:00
武汉 华中科技大学 华中科技大学学生活动中心513 10月13日 18:30
西安 西安交通大学 就业中心信息发布大厅 10月20日 14:00
更为具体的招聘职位，请访问支付宝招聘页面，这个页面还会持续更新。
--EOF--
A: 动态连接器（dynamic linker）决定使用哪个操作系统 ABI (Application Binary Interface) 库的。LD_ASSUME_KERNE 的值要设定为操作系统版本号。比如 2.4.1 。更多参见 Metalink 文档：433292.1 。
补充：在 Glibc-2.5-20 以上版本修复。各发行商有单独的版本。RHEL 4.x 中在 4.7 以上修复。不过 RHEL 4.7 Kernel 也有问题。
其中一个是 Root device MPIO support，尽管可能没有人会在根设备用 MPIO. 另外一个是 I/O-AT 的支持，I/O-AT 是 Intel 的网络加速技术. 第三个是 Dynamically switchable per-queue I/O schedulers 。
零星记录的一点东西，以后想到什么再补充。 另外，推荐一下 hutuworm 同学的 BLOG 。很有嚼头。
--EOF--
我们到的时候，Ivar Jacobson 正好开讲，演讲的内容可能很精彩，那个 PPT 说实话真是挺一般。我倒是直接被现场的 叽歪 互动大屏幕吸引住了，巧的是，叽歪的展台上座位空着，我就不客气的霸占了。折腾了半天，才把笔记本的无线硬开关打开，然后抢了半天信号。发出了第一句消息。
没想到这一发就不可收拾，信号越是抢不到，越是想抢。上午刚开始的时候大屏幕显示的消息基本上是报道消息和广告消息。到了 SAP 芮祥麟 和接下来的庞升东演讲的时候，大屏幕上的互动明显更活跃了。可见这两位演讲水平其实...芮 居然跑这里来谈什么 80/20 法则，而庞的 PPT 也太粗糙了一点。倒是 Google 的那位用几幅图蒙了不少人。毕竟好图值千言。不过也有眼尖的朋友说 "张先生还没有使用 chrome"。这时候现场抱怨无线信号不好的人越来越多(1, 2.)
电梯演讲的时间还是很有趣的。因为每个人只有 5 分钟要展示自己的项目。所以第一个上去的词网科技的张跃语速那叫一个快啊，但"不要学韩乔生老师"嘛。他在台上的时候我才发现就是刚才坐在我旁边的人，我还开玩笑说, "真是静如处子，动如脱兔啊". 而庄表伟的 PPT 第一句赫然是"十一届三中全会以来"，把所有人都震了，现场笑翻，"雷的我们外焦里嫩"。淘宝的兄弟们说"要顶"。电梯演讲结束后的 VC 点评就不说了吧，还不如台上的几位话语简洁呢。大屏幕上看到有人质疑：咱们这次会议的主题是技术呢还是找VC投资呢?
说说中午吃饭这个恼火事儿。签到的时候，发现参会证里面没有中午餐券，问了工作人员说过一会儿给我们补发。有了这句话，中午到吃饭的时候，淘宝、B2B 的几个兄弟跟我开玩笑说跟着我有饭吃，可被告知没餐券了。这里要批评一下有的工作人员，来的都是客，不能厚此薄彼，外面下着大雨，要我们到哪里去找餐馆 ? 也要批评一下组织者，发了多少张参会证还不知道么? 之前的大段时间就不能重新计划一下如何解决参会者用餐？
还好，凑巧碰到了蒋涛，我抱怨了一句，蒋总，兄弟们还没饭吃阿... 还好，这句话问对人了，总算拿到了另外几张餐券。蒋总涵养就是好，换了别人，谁还理你?
中午回来，孟子E章发消息说"没吃饱"，还有人没饭吃呢... 孟岩的演讲很赞。简明扼要，起码能让我用心听了。这时候我终于有"专线"了。发消息总算不在丢失了。而接下来的这个 IT 人士英语解决之道的演讲实在有点不招人待见。屏幕上出现了本次活动最 Geek 的一则消息，接着出现的消息更让大家捧腹：
尽管这会儿的演讲最没劲，可台下的 Geek 们实在是最 Hi 的时候，估计那老师听着一阵阵莫名的笑声也发毛。
英雄会，会英雄。下午有一阵感觉我这个 ID (dbanotes) 上镜次数太多了，跑外面歇会儿。和范凯(Robbin)、阿朱、刘韧、张银奎(《软件调试》作者，这会儿我还不知道他是这本书的作者，倒是问了一些 Intel 官方 Blog 的运作的事儿)聊了一会儿。然后在图书展台看到了周筠老师以及图灵的几位编辑。还有 51 的桂新、好多人在找的车东...
回来的时候正是下午的电梯演讲时间。Para Engine 的演示倒是挺吸引人，不过直接说是"Second Life" 的中国版估计VC 就明白了。经过一上午的互动，大家对叽歪网其实也知道是怎么回事了。李卓桓的展示反而有些"绕"。倒是接下来蔡世友的演讲把很多人"震"了, "中气很足", "这哥们儿嗓门真大"。
这里说说我自己对电梯演讲的看法。作为一个演讲人，你前三句要说清楚"你是谁"，"项目是干什么的"，"项目面向的用户是哪些人"这三个问题。如果三个做不到，那么前两点肯定要说清楚。只有 5 分钟，别太着急（你说的越快别人越记不住东西)，你也别寒暄，也别描述什么应用场景(比如李卓桓)，说不清楚项目是干什么的，就说出来这项目"像"谁，接下来点一下与被模仿者之间的差异就行了。如果能有个互动演示是最好的，这比语言描述更直接，而且时间容易控制。有一点值得提醒一下，似乎没有人提及自己的团队，都只介绍了自己。
这时的一个小花絮是唧歪大屏幕上出现了寻找 "hero2008" 这个 ID 的活动（0，1，2，3，好多人感觉消息被屏蔽了不少，激起民愤了 :)
另一个小花絮是说 51.com 的开放平台支持 51ML什么的，然后好多人都在问这个 ML 是什么单词的缩写， 哈哈。
接下来的网络英雄论坛和 CTO 论坛似乎稍有点沉闷，个人感觉如果同时安排到两个会场可能效果会好很多。
因为要赶着回杭州，在大约 5点的时候就撤退了。当然临走也没忘广告一下：
支付宝公司近期将在上海举办专场招聘会,期待各路英雄加盟！此时此刻,非你莫属！参考: http://job.alipay.com/
本来支付宝也是会议的赞助商的。原计划还要在会场放置两个易拉宝做宣传。可惜易拉宝坏掉了。还好有叽歪大屏幕在。这也是我在会场频繁发消息的一个原因（如果大家对支付宝感兴趣，请联系我或者把简历发到 [email protected] ，我帮忙推荐）。当然另一个主要的原因也是好玩 :) JUST 4 FUN
最后唠叨几句对会议的感受。首先说叽歪互动大屏幕。尽管有人说可能会喧宾夺主，可对大多数技术人员，尤其是 Geek 来说，没有了这个会让这个会议很无聊(又那么一瞬间，我甚至以为到了中文网志年会会场)。但我不是说叽歪有多出色，我本人是 Twitter 的重度用户，现场用叽歪这个过程已经感觉有些地方的设计仍有改进的余地。另外，会议现场的互动不是多，而是太少了。尤其是缺乏交换名片的互动场景。IT 人员社交圈子也要打开。
批评一下会场的无线网络，真叫一个差。就这么一个弹丸之地，布署一个可靠一点的无线网络难么? 应该不是，只是没有用心罢了，我甚至看到还有一堆没拆封的无线路由器闲置在那里。
然后是前面说的用餐问题。不要让大家饿肚子。而没吃到饭的人肯定中午一去不复返了。尽管有意见，最后还是说，CSDN 的活动挺成功的，谁都知道，搞这么大的会议不容易。
最后说一下，认识了很多新朋友，见到了许多老朋友，在这里可能没提到您的名字，别介意，回忆断断续续的，文章容量也有限。
--EOF--
补充：1) 这次发现阿里集团内部 Geek 真是非常多啊。大家现场玩的都很高兴。粗略的找了一下，ID 有：超时空宝宝(refer)、tellee、Liang.ChenL、赵小马等。
2) 更多朋友参会感受。
这是前一段时间《程序员》杂志采访支付宝架构师团队的的稿件。篇幅较长，此为第二部分。。
本周支付宝架构师团队一部分成员将参加 CSDN 上海英雄会，欢迎做些技术或者业务方面的交流，
尤其是支付宝的一些合作伙伴公司和潜在合作伙伴公司。
书接前文
的确，支付宝的数据堪称海量，但相比之下，主要的压力还是来自对交易事务的处理上。我们也有一些密集型的后台计算，但相对规模不算特别大，当前的计算能力足以支撑，当然，我们也尽量会想办法用更小的成本提供更强的计算能力。
对于云计算，我们目前还没找到很合适的应用场景，但整个架构组目前对云计算保持密切的关注，并会投入适当的力量进行一些前瞻性研究。我们实际上更为关注一些解决方案，比如 Hadoop ，并准备在 DW/BI 方面进行一些尝试。
通常情况下我们的技术架构是可支撑产品设计的多样性需求的,但仍有部分产品设计因市场的差异化需求非常特殊,造成我们的技术架构要支撑这部分产品产生了一定的挑战,这也是因为我们的所处的行业是一个迅速发展的行业有关,一方面我们加强技术架构的灵活性和前瞻性研究，另一方面我们也同时加强对产品设计的规范指导,使其两者达到平衡。
我们在技术架构的发展上做了很多课题性研究,如遇到新产品的设计技术架构无法支撑的情况下我们对产品所带来的收益与需扩展技术架构的投入成本上做出分析权衡.
现代大型系统中，Cache 是个非产关键的组件，在具体实践中，我们会依据支付宝自身的数据特点对数据部署缓存策略，支付宝对数据实时性的要求造成Cache的准确性要求极高，而数据的私有性造成提高Cache命中率难度较大。客观地说，目前对于 Cache 的利用应该说还不是很充分，这有待于我们进行更深入的研究。
简单的说几点经验，一个是要合理的选择 Cache 所在的位置. 简单的说，Cache 的位置有几个地方:
Web服务器层 -> 应用服务器层 -> 数据库层
具体使用哪个 Cache 以及在哪个位置来做 Cache，要依据缓存什么、性能要求、数据量、可伸缩性、事务要求、过期特性、一致性要求、可复制性、硬件投资、开发投资多个维度来考虑。如果 Cache 的位置选择不合适，那么系统伸缩性会受到严重影响，每次 Cache 系统实施之前，需要架构师进行充分的论证和评估。
第二点，在Cache 存储的资源粒度，需依据 Cache 资源的特点，比如登录者基本信息，就完全可以一次性缓存起来，对于聚合关系结构的业务对象，在缓存的时候需要考虑业务特点，如果业务上对聚合对象内部的对象访问就很频繁，那么就考虑选择小对象力度缓存，否则考虑大粒度对象。第二点是Cache自身的特点，本地JVM Cache，可以考虑存储大对象，因为此时没有网络访问、数据流量的考虑，那么即使业务上小对象访问比较多，也可以考虑完全缓存整个对象关系；如果是远程 cache，那么就要依据大粒度和小粒度对象访问的频率，然后决定。
Cache 是个非常庞大的话题，如有必要，可以选择另外的时间进行探讨。
考虑到支付宝的业务特点， 无论我们做什么应用，安全性、可靠性肯定是排在第一位的。然后我们会重点考虑性能和可扩展性。支付宝现在已经是最大的第三方支付工具，日益增长的交易量给架构师们带来了很大的挑战。我们在具体实践中也从BASE 策略中得到很大参考：
Basically Availble --基本可用
Soft-state --软状态(柔性状态)
Eventual Consistency --最终一致性
目前的拆分原则主要是遵循 SOA 的思路，面向服务进行拆分，这也是基本原则之一。 至于是否按照用户拆分，只要不违背 SOA 即可。
开放平台这个词最近确实非常火，好像一夜之间大家都开放了。开放确实是一种趋势，任何一个互联网公司都只是整个互联网生态圈中的一环，只有开放才能让自己更好的融入到整个生态圈中。这是大方向，大方向确定了，剩下的事情就是如何开放，开放什么的问题了，这也是每个互联网公司需要仔细考虑的问题。
我觉得随着公司业务的不断发展，开放是一个必然的结果，我们在支付宝创建初期就意识到整个支付市场是非常大的，在服务好淘宝的基础上应该大胆的走出去，去为更多的电子商务平台提供支付服务。所以，我们很早就推出了支付宝商户平台，在这个平台上我们提供了大量的交易、支付服务。通过这几年的运营，我们确实尝到了开放的好处（外部商户为我们的交易量做出了很大贡献），同时我们也积累了很多开放的经验。目前我们正在开发一套新的开放平台，我们希望通过这个平台，可以为我们的合作伙伴提供更多、更好的服务，同时也希望有更多的第三方公司能在我们提供的基础服务之上，创造出新的商业模式。
如果说"面向服务架构"使企业IT系统支持业务敏捷化的话，开放平台则是使互联网大系统支持整个行业生态圈的业务敏捷化。开放平台、是企业追求开放式成长的必然道路，也是SOA原则走出企业系统的狭小圈子、在广袤互联网上的自然延伸。以支付宝的实践来看，在2005年中，支付宝就针对互联网交易提供了API，为互联网上的电子商务提供安全交易与资金流解决方案。随着业务领域不断拓展，原来的从需求->解决方案->产品->API的方式，周期太长，已经难以快速满足大量合作伙伴的需求。因此，支付宝现在正在由产品式的开放转向平台式的开放，通过加强开放基础设施的建设，向合作伙伴提供更基础、更可重用、更体系化的服务，达到与合作伙伴充分协同，建设繁荣、共赢的电子商务生态圈的目标。
同时，开放的业务服务与开放的技术平台也正在推动支付宝的业务与技术架构向前发展，对构建更大规模的分布式系统、更大规模的并行研发模式都带来了积极而深远的影响。
技术不是一蹴而就的事情，而是长时间积累的成果。此外，扎实的基本功是做好所有事情的开始！抽象的能力也是作为一名好的程序员必须具备的，我们在考虑问题的时候可能会遇到错综复杂的场景，从这些迷雾中找到一条明路是我们做好程序员的关键。实际抽象能力衍生出来的一点就是需要我们对已学过的知识定期的进行梳理，这样能让你稳固已有的知识，为以后学习的更多的知识做好准备。
实践也是非常重要的一个环节，不要有畏难心里，觉得这个东西非常的难，我无法完成！有时候你去完成一件事情，事情的结果可能会是糟糕的，但是解决这件事情的过程是非常宝贵的，你可以在这个过程中学习到很多东西！最后我还要说一点的是，业务知识非常重要，这个是你实践的关键！(by 胡喜)
架构师在设计系统架构，或者对重大问题进行决策时，必须在全面考虑各种因素、充分前瞻的基础上做出全局最优的选择。这种整体性与发展性的思考模式是一种能力，也是一种习惯，一种态度。作为有志于成为架构师的开发者，应该在日常开发中就养成站在整体、发展的角度去理解、分析、与解决问题的习惯。(by 程立)
再补充三点:
架构师在成长过程是个顿悟的过程，需要自己注意及时总结，尤其是不可能不犯错误，但是需要自己通过每次所犯的错误进行深刻的总结提升自己。提升的过程是个螺旋式上升的过程，自己以前也做失败过一个案例，至今记忆深刻，通过这次深刻的教训，对自己的成长是很有帮助的。遇到错误不要怕，要坦然面对，能做到:犯错误-->提升-->避免错误就可以了。(by 王学安)
1，架构师往往是领域专家，持续关注领域发展和创新、领域知识，了解领域需求，并将领域需求不断的融入到架构模型里，侧重领域功能布局。
2，架构师往往是技术专家，持续的关注技术知识，架构模式，设计模式以及技术规范等，技术架构关注点可以是，开发高效、复用、安全、可维护可管理、灵活等。
3，实践出真知，持续关注领域、技术，勇于实践。( by 刘明源)
附录：可能有的朋友已经知道支付宝的花名文化，这次接受采访的同事花名可以列一下：鲁肃、苗人凤、西毒、阿玺、邓芝、庞统、夫差、李磊、俊义。(猎头们就别盯着这里看了，做点有技术含量的事儿吧)
--EOF--
这是前一段时间《程序员》杂志采访支付宝架构师团队的的稿件。篇幅较长，此为第一部分。。
本周支付宝架构师团队一部分成员将参加 CSDN 上海英雄会，欢迎做些技术或者业务方面的交流，
尤其是支付宝的一些合作伙伴公司和潜在合作伙伴公司。
Note：提问者：《程序员》杂志郑柯。回答者：支付宝架构师团队。
支付宝架构团队里的架构师角色可以划分为首席架构师、技术架构师、业务架构师、产品架构师等、数据库架构师等。
此外，我们支付宝架构团队里面还有搜索引擎专家专门负责搜索相关的技术，有业务流程专家制定业务流程制定，流程架构开发指引等，可谓藏龙卧虎。
支付宝的架构师中，一部分是从支付宝与淘宝网的内部一线研发人员中成长起来的，在多年的实战中积累了丰富的大规模分布式互联网系统的设计与开发经验，有扎实的 Java 开发功底，熟悉各种开源系统、框架与工具，熟悉主流的企业中间件。支付宝架构团队也有一部分是来自著名 IT 企业的架构师，他们分别在数据库、高性能计算、企业服务总线、工作流、开发工具等专业领域有多年的积累。
支付宝架构师对电子支付行业知识有相当深入的了解，尤其我们的业务架构师，他同时也是会计与支付行业应用的专家。另外，值得强调的是，每个架构师也都会定期带一到两名徒弟，把经验直接传递下去，满师之后徒弟也会承担比较关键的角色，这也让开发团队的同事有更好的上升空间。
支付宝架构团队的日常工作定位在支付宝系统高层架构的设计与优化，其职责是保障系统与公司的愿景与业务体系一致，达到关键的业务敏捷、可伸缩、高可用、性能与安全指标，具备内在的统一性、协调性与可持续发展性，支持支付宝技术团队高效率地研发高质量的产品。
为了达成这一目标，我们会创建并持续优化支付宝的业务架构与系统架构蓝图与发展路线图、参与各类外部与内部标准与规范的制定、评估与指导重大项目与重大的系统变更、主持设计并实现支付宝系统开发框架与工具、以及辅导与培训支付宝技术团队成员等。
支付宝架构团队同时是支付宝未来发展所需的关键技术的孵化器。我们会根据公司的业务方向与趋势，结合行业与技术的发展状况，产出并维护支付宝的技术愿景、技术研究整体规划与发展路线图，并主持开展前瞻性技术的研究。
支付宝架构团队也是公司决策层的智囊团之一。我们会参与公司的发展决策，站在整体业务与技术架构、技术可行性与最佳技术途径的角度，对公司重要项目的决策提供专业性的参考意见。
补充一下，支付宝架构团队一直在招贤纳士，欢迎更多技术牛人加入(Fenng 补充：另外近期在上海会有招聘会)。
沟通是比较多的，一方面是在项目期间会有比较频繁的沟通，主要集中在产品的系统设计是否合理、技术难点支持等方面，有的时候，架构师也会临时"下放"到项目组，与开发工程师并肩战斗；另一方面在非项目时间经常会针对开发模式、新技术走向、如何做好设计和编码等技术角度做分享与交流。
架构团队内部的小范围沟通也不少，大家经常会就一些难点进行思维碰撞、分享、交流。 我们架构组后面的白板好像很少有干净的时候 - 经常是在讨论中拓扑图画满了整个白板。
为了促进阿里巴巴旗下的各个子公司之间的技术交流，我们成立了一个集团架构委员会。集团架构委员会每个月会有一次线上交流，每个季度会有一次线下的会议交流，而且每个月末各个子公司都会在邮件列表中报告各个子公司技术研究方向和成果。
如果大家都在研究同一种技术，会成立专门的研究小组，进行针对具体技术场景的研究。通过集团架构委员会，我们可以了解各个子公司的技术方向和研究成果，做到互相促进，互相学习，技术共享。
在过去的三、四年里，随着支付宝业务领域的拓展与业务规模的增长，支付宝系统也一直处于快速的增长与变化中，从最初的单一应用迅速发展成由数十个自主系统构成的高度分布又充分协同的大系统。与此同时，支付宝研发团队的规模也从最初的数人发展到现在超过百人的研发团队。在快速奔跑中保持稳定与平衡，对架构提出了很高的挑战。
因此，我们很早就将支付宝系统建立在了面向服务架构(SOA)之上，确立了面向服务的整体业务架构，围绕着公司的基础业务建设了几大核心服务系统，并且搭建了以 ESB 为骨干、以服务框架为基础的面向服务基础设施。这些核心服务以及基础设施是支付宝系统健壮的后腰，它们的高可靠与高可用性是支付宝系统的整体稳定性的基础，它们的灵活性与可重用性支持前端业务有条不紊地创新、整合与优化，它们的可伸缩性保证了系统能够支撑持续的快速业务增长。
面向服务架构不仅是支付宝的运行系统的基础，而且已经渗透到了支付宝的研发与治理体系中，当前，这个领域仍然是支付宝架构团队的一个研究与应用的重点。
支付宝从05年开始规划、研究SOA；在06年开始实施第一个SOA项目，同年引入ESB产品，对SOA相关的思想、技术进行验证和探索；经过几个项目的实施，我们完成了第一阶段的规划和目标，实现了几大核心业务的SOA化，构建了一套支撑SOA的技术平台。
从理论到实践上，都积累了丰富的经验，下一阶段，我们将会在深入业务SOA的同时，不断完善和发展我们的SOA技术平台。
在采用SOA思想的过程中，我们从下面2个方面入手：
首先，从业务层面入手，用SOA思想梳理业务架构。化解业务敏捷的要求，同时支撑支付宝的开放战略。在此之前，我们在进行业务架构分析的时候，更多的是关注业务的合理性，可行性等，在业务发展的初期，这种做法能够满足我们快速开发系统，及时占领市场的需要。在05年中，我们预见到现有的业务架构，将不能支撑我们公司快速发展的需要，例如：我们的注册会员飞速奔向1亿。此时，我们就开始探讨和规划SOA思想。因此在06年，我们果断的引入SOA思想，用SOA的思想不断重构我们的业务架构。在这个过程中，随着数次公司战略的调整，业务架构都能够灵活应对，达到了业务敏捷化的目的 -- 这也是SOA思想的核心。
业务架构的SOA化，是我们开展技术SOA的一个充要条件，没有这一步，我们将会非常艰难，甚至无从下手。
接着，技术层面的SOA，构建一个适合支付宝的SOA技术平台，来支撑业务SOA化的需要。针对支付宝的业务特点和要求，我们优先考虑实现如下SOA要素：
A：以服务为基本单元。技术平台提供与之对应的组件编程模型，业务层面的每一个服务，都能够方便的封装位技术层面额一个组件，例如：客户系统中的注册、登录等，都对应一个组件，每个组件都是独立的，在部署的时候，我们可以灵活选择和组合,可以依据SLA的要求，做出多种部署策略。
B：基于统一标准。在此，我们选择了ESB产品提供支撑，对外提供SOAP、REST、Hessian等标准的支持；对内统一采用定制的标准。
C：分布的能力。所有的服务都能够透明的分布，为外部消费者使用。
D：鼓励扩展。技术平台提供扩展的能力，例如：客户注册后的业务扩展点，业务部门要求依据客户注册来源、客户所在省、客户年龄等，进行不同的业务处理，而且这些业务点有些要求在事务中，有些要求在事务之外。如果每次新的需求出现，都在原有系统直接进行修改，那么不但可能破坏原有的业务，而且可能导致系统可维护性变差。提供扩展点功能，将把扩展逻辑和主体业务逻辑进行有效的隔离，能够彻底解决上面的问题。
E：支撑业务敏捷。支付宝的交易流具有流程类型多，流程过程繁杂的特点，业务流程每个月都会提出多种新的交易业务，同时我们的业务从单一交易业务流向整合型业务流发展。因此，我们引入了BPM相关的技术和工具，帮助我们方便，灵活的组合服务，定制流程。
--待续--
配置好 Nginx 后，可能有的朋友还想用 Awstats 分析日志。如果另外再起一个 Apache ，觉得费二遍事。如果在 Nginx 上跑 Awstats ，还需要 FASTCGI 支持。配置的方法有些山寨。Nginx 尽管提供 Perl 模块支持，毕竟还是实验性质的。
对比了一些文章，决定还是用 nginx-fcgi 这个脚本。作者是 Daniel Dominik Rudnicki 。这个脚本要比顺子文中提到的要好一点。
该脚本中用到如下的 Perl 模块。所以使用前要确保相关 Perl 模块已经存在。要不，手工下载安装一下。
使用命令示意：
/usr/local/nginx/nginx-fcgi -S /tmp/fastcgi.sock -l /var/log/nginx/nginx-fcgi.log
-pid /var/run/nginx-fcgi.pid
网上常见的那个脚本必须要显示的指定最为后台进程跑。不是很完善的方法。
注意事项：不能用 root 用户执行(会提示). 要用与 Nginx 相同身份的用户执行。否则可能会在 Nginx Log 中提示 Permision Denied 。
Nginx 中配置好 Log 格式：
log_format main '$remote_addr - [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer"'
'"$http_user_agent" $http_x_forwarded_for';
相对应的 Awstats 中 Log 格式为：
LogFormat = "%host - %time1 %methodurl %code %bytesd %refererquot %uaquot"
其他的配置参考一下Sunnyu 的 "为了Awstats给Nginx添加FastCGI方式的Perl支持" 应该就成了。
BTW: 应该说，Nginx 能够有效抵挡搜索引擎爬虫对网站的影响。对于 Apache 来说，这是个很大的进步。
--EOF--
更新：如果手工写脚本做 Nginx 日志 logrotate 的话，注意不要简单的用 mv 命令, cp 然后 echo ''> 的方式更好。
推荐： Sina 张宴的 Nginx 0.7.x + PHP 5.2.6（FastCGI）搭建胜过Apache十倍的Web服务器（第4版），这是目前关于 Nginx 最详细的实践文章。
