May 2008 Archives

用什么来衡量一天没有白过? 可能看到一篇好文章能算做一个条件。infoQ 上的这篇 Scalability Best Practices: Lessons from eBay 会让每个架构师都比较激动的。

过几天估计 infoQ 中文站就翻译这篇文章了，所以只记录一点自己的想法好了。在其中的 7 个实战经验中，每一条都值得写篇学习笔记，我比较关注面向 DB 的几条。

水平切分

对于 eBay 这样个头的大 Web 应用，如果数据不能分片，就无从谈及扩展。这个话题我之前描述过一点，文章中提及数据库层的切片要比应用层复杂许多，我想其中最大的一个难点就是不同用户之间的关联数据问题吧，否则就完全可以根据用户范围或者群体划分到不同的 DB 上。现实的应用总是如此复杂，让每个架构师都早生华发啊。

避免分布式事务

其中提到的前 Inktomi 工程师 Eric Brewer 提出的 CAP 定理： Consistency (C), Availability (A), Partition-tolerance (P) ，最多能同时选择两个。三个不能同时实现。对于 eBay ，选择的是 A 和 P，牺牲了一致性，而通过系统的其它手段(比如事件系统)来追回事务的完整程度。BTW: 这次倒是没有提及 BASE :)

虚拟化所有层次

这样做的目的是为了达到编程上的方便以及运营操作的灵活性。通过 eBay 的 O/R 层实现了对数据库的虚拟化。这样应用程序开发者无需关注数据存在哪里的。

Cache

其中提到了 Cache 的应用场景：针对缓慢改变的数据、只读为主的数据、元数据、配置信息和静态数据等。 把握这个原则是很关键的。我个人就看到有病急乱投医的设计者把数据一股脑的扔进 Cache，潜在的麻烦很难消除。

强烈推荐大家直接点过去看一下该文。

补充：关于 BASE。
Basically Availble
Soft-state
Eventual Consistency

--EOF--

由几位前同事秘密打造许久虾米音乐网明天正式上线测试了。虾米是干啥的? 比较官方的描述是 "P2P音乐分享平台" ，站内有篇360度全面了解虾米(登录才可以访问)，我个人的看法是 "Last.FM + P2P"。对于音乐源，永远有"种子"。这一点能弥补当前很多音乐站点的缺陷，至于版权问题如何解决，你登陆后就知道了。

去过虾米的办公室，这帮家伙本身就是铁杆乐迷，对于互联网存在的各种模式也研究比较透了，所以，虾米的玩法总有些与众不同之处，当然这也要看网站的发展和用户的接受程度了。 祝他们好运!

虾米的主要技术包括：基于 P2P 技术的娱乐媒体传输和提供用户良好的娱乐享受，及从分享中的获利。采用跨平台的 C++ 技术进行 Linux（服务器）和 Windows（客户端）的技术开发，服务器侧重于高性能和并发性，客户端侧重良好的用户体验和用户媒体习惯数据的采集。

小道消息: 他们在招聘(简历发给我即可)

Windows程序员

1. 精通或熟悉C++，能熟练使用VC，熟悉网络编程(Socket，完成端口)和UI界面(SDK，GDI，GDIPLUS)编程，了解P2P技术尤佳 ；
2. 熟悉面向对象，STL，ATL等C++语言层面的技术 ；
3. 熟悉多线程编程 ；
4. 熟悉SQL编程 ；
5. 能熟练查阅英文编程资料(如MSDN) ；
6. 对互联网行业充满热情和兴趣，具有优秀的学习能力，喜欢音乐者尤佳。

1. 精通C++，能熟练使用VC，精通网络编程(Socket，完成端口)和大并发的服务器架构设计。对P2P技术有深入研究者尤佳；
2. 精通面向对象，STL，ATL等C++语言层面的技术。熟悉boost，loki等模板库者尤佳；
3. 精通多线程编程；
4. 精通或熟悉SQL编程，熟悉MySQL，SQLite者尤佳；
5. 能熟练查阅英文编程资料(如MSDN)，具有良好的编程规范并能指导他人；
6. 对互联网行业充满热情和兴趣，乐于助人，喜欢音乐者尤佳。

1.两年以上互联网应用开发经验；
2.熟悉PHP.MYSQL.LINUX.Apache.Janascript.AJAX；
3.有大型网站架构、系统优化，SEO工作经验优先；
4.熟悉各种PHP框架优先。
5.喜欢音乐优先。

目前虾米音乐网还要邀请才能注册，我有几个注册名额，基本用没了。还记得我说过的 Paypal 黑帮的故事么? 新的黑帮已经形成规模...

--EOF--

关心 Web 2.0 的朋友对于 LinkedIn 应该都不陌生。我这个 Blog 上以前也介绍过 LinkedIn 的架构信息。最近, LinkedIn 公司的两位工程师在 JavaOne 上做了两个分享。揭示了更多 LinkedIn 架构方面的技术信息。

1) LinkedIn - A Professional Network built with Java Technologies and Agile Practices

这是我看到的 Web 2.0 公司中第一个完全拥抱 SOA 的。这个文档中大致描述了 LinkedIn 开发过程上的一些经验。

| View

News Service Architecture 对于国内鲜果这样的 RSS 工具网站或许能有点参考价值。另外一个值得注意的地方是架构的变迁，随着业务的增长，后端 DB 的变化非常明显。

2) LinkedIn Communication Architecture

这一篇中描述了几次迭代经验，其思路值得借鉴。

| View

其中提到了对 CLOB 字段的更新认识。我个人的建议是：不到万不得已，还是别在 Web 应用中用 CLOB 了。

--EOF--

同事在 Linux 服务器上遇到点小问题，我也上去折腾半天。这还是第一次注意到 Linux 这个多年来就存在的特性：OOM Killer 。说白了 OOM Killer 就是一层保护机制，用于避免 Linux 在内存不足的时候不至于出太严重的问题，把无关紧要的进程杀掉，有些壮士断腕的意思。

先要学习点老知识，在 32 位CPU 架构下寻址是有限制的。Linux 内核定义了三个区域：

# DMA: 0x00000000 -  0x00999999 (0 - 16 MB) 
# LowMem: 0x01000000 - 0x037999999 (16 - 896 MB) - size: 880MB
# HighMem: 0x038000000 - <硬件特定> 

LowMem 区 (也叫 NORMAL ZONE ) 一共 880 MB，而且不能改变(除非用 hugemem 内核)。对于高负载的系统，就可能因为 LowMem 利用不好而引发 OOM Killer 。一个可能原因是 LowFree 太少了，另外一个原因是 LowMem 里都是碎片，请求不到连续的内存区域【根据我遇到的一个案例，一个猜想是 有些应用一次性请求比较大的内存，恰恰又是 880M 之内的，空闲的(LowFree)不够大，就会触发 OOM Killer 出来干活】。检查当前 LowFree 的值：

# cat /proc/meminfo |grep LowFree 

检查LowMem内存碎片：

# cat /proc/buddyinfo

上面这条命令要在 2.6 Kernel 环境下有效。据说使用 SysRq 的方式更好，不过 Hang 的时候再用吧。参见 Metalink Note:228203.1 。

根据一些文档描述，OOM Killer 在 2.4 与 2.6 上表现是不一样的。2.4 的版本中是把新进来(新申请内存)的进程杀掉。而 2.6 上是杀掉占用内存最厉害的进程(这是很危险的，很容易导致系统应用瘫痪)。

对于 RHEL 4 ，新增了一个参数： vm.lower_zone_protection 。这个参数默认的单位为 MB，默认 0 的时候，LowMem 为 16MB。建议设置 vm.lower_zone_protection = 200 甚至更大以避免 LowMem 区域的碎片，是绝对能解决这个问题的(这参数就是解决这个问题出来的)。

而对于 RHEL 3 (Kernel 2.4) 似乎没什么好办法，一个是用 Hugemem 内核(天知道会不会引入新的毛病)，一个是升级到 2.4.21-47 并且使用新的核心参数 vm.vm-defragment 控制碎片的数量。再就是使用 RHEL 4 (Kernel 2.6)，这又绕回去了。说白了，如果遇到 OOM Killer ，基本上是低版本 Kernel 设计上有点缺陷。

其它，如果去查询 RedHat 的 Bug 库，会发现不少 Kernel 版本也有 Bug 的。尤其在使用 NFS 的场景。

Tip: OOM Killer 的关闭与激活方式：

# echo "0" > /proc/sys/vm/oom-kill 
# echo "1" > /proc/sys/vm/oom-kill

更多参考信息:

• 1) OOM killer "Out of Memory: Killed process" SOLUTIONS / SUMMARY【对我遇到的案例没鸟用】
• 2) Metalink Notes : Linux Kernel Lowmem Pressure Issues and Kernel Structures
• 3) Respite from the OOM killer

--EOF--

头疼欲裂，零散记录点东西，备查。

微软对 Yahoo! 的收购持久战可能让很多人都新闻疲劳了。但今天看到的这个关于 Yahoo！ 的技术新闻还是值得看一下的：Size matters: Yahoo claims 2-petabyte database is world's biggest, busiest 。Yahoo! 的 VP Waqar Hasan 在文中披露 Yahoo！的数据仓库当前容量为 2PB。用于分析每月5亿的用户访问行为，每天处理 240 亿次的事件，号称世界上单个最大、最忙的数据库。

尽管有的数据仓库容量要比雅虎的大。但那些 DB 或是存储非关系性数据，或是存储的压缩后的原始数据，不能进行即时分析，雅虎之前的也有数百 T 这样的数据。眼下 Yahoo！数据仓库存储的是结构化、可分析的数据。预计下一年可能膨胀到数十 PB 。eBay 号称数据总量有 6PB ， 不过根据一些消息来看，单个最大的 DB 只有 1.4 PB。

Yahoo! 在 2005 年买了一家叫 Mahat Technologies 的初创公司（就是 Waqar Hasan 操刀的)，这家公司以 PostgreSQL 数据库为基础，开发了一个新型 DB，其特点是 基于列 的而不是 基于行 的模式。不难理解，这样数据写入的速度会慢下来，但是读取的速度会快很多【去年的侠客行上，雷鸣在演讲的时候讲过他在百度的时候做的一个优化的例子。和这个思想非常相似，所以当时我说对我"有启发"】。Yahoo! 买了之后，对该产品进行了持续性的改进(内部代号: ELCARO ?) ，比如压缩，并行处理能力加强、优化查询等等特性的添加改进。而针对使用者的接口仍是 PostgreSQL 。这应该也算 PostgreSQL 在顶级企业又一个成功案例。

这么大的数据库并没有采用传统的 SMP 架构构建，而是采用普通 PC 作集群(用了不到 1000 台) 。很明显这是 Share Nothing 而不是 Share Storage 的 DB 集群。通过上述独特的设计方式，能够对此海量数据进行有效的分析，这是个不小的技术革新，也是与 Google Map Reduce 完全不同的计算模式。

让人感慨的是 关于世界上的超大数据库 一文中罗列的数据，现在看起来已经并不惊人了。以前总说信息爆炸，这个时代刚刚来临。

--EOF--

从侠客行会议刚回来。不要问我技术内容了，只是简单记录一下流水涨吧。

早晨还没洗漱完毕就有朋友给我打电话询问门票的事情，赶紧出门赶到了会场。在大门口附近送了一会儿票(其实到了现场就知道对门票的控制没那么严格，基本上都能入场，只是答应了大家的事情，就尽量的要做到。希望没有朋友因为没门票而觉得不爽)。差不多后，进入五楼的主会场。

会场内为每个参会者准备了一个资料袋，环保的 "I'm NOT a plastic bag"，值得一提。一开场的大屏幕动画做的很好，伴随着鼓声，一个个武功高手动作各异的剪影飘过，估计那会儿会场里的人都会比较激动。

在会场里遇到了客奇集的陈成罕，对我的 Blog 提了点意见：为什么技术细节不够多? 唉，其实当时没告诉他的是，我也想多加点技术细节，只是...... 这次他们那边一共来了六位工程师，其中还有不老歌的 York ，下午的时候终于看到了 York，可惜没能畅谈。在会场边上走进走出的（我这是来参会的么?)，听演讲的效果并不是很好。对陈世卿博士的主题演讲比较感兴趣的，尽管了解不到实际的内容，但毕竟是见证计算机发展历史的人，沾点仙气也不错的。David Axmark 看起来是个绅士，语气淡然。老马演讲开始的时候几乎所有在走廊里的人都回到了会场......老马明显比前一段时间瘦了很多--本来就瘦

在会场外和组织这次会议同事聊了一会儿，他们也不容易，世界上哪有十全十美的会议呢? infoQ 、博文视点、CSDN 的编辑朋友也都见到了。这次 InfoQ 还是会议的合作媒体，上午自己接受了他们的视频采访，现在回想起来时候发现大部分的话题都落在 Web 2.0 上了，不知道是否很合适。对于这样的采访没啥经验，等待出来的效果吧。大家都是不错的朋友，所以也建议他们别错过对支付宝我另一个同事的采访。

下午先是听了半场 A Look at Hadoop ，这本应该是个很有趣的话题，可惜现场效果似乎并非很好，本来准备了要问个问题的。接着就去配合 InfoQ 编辑对支付宝首席架构师程立的采访去了。采访效果我觉得非常好，我自己也听的很过瘾。希望能早点看到整理后的采访内容。

采访完毕出来，到二楼去找刚赶到杭州的车东，客奇集的朋友们也都在这里，把 Yupoo 的阿华同学也给大家介绍了一下。比较可惜的是晚上没有安排什么技术交流，否则这么多朋友聚在一起倒是能大聊特聊的。

听完了 Flickr Architecture 这个主题高屋建瓴般的讲座，会议就结束了。在会议结束的时候随车东和淘宝的卢亮聊了几句，尽管在同一个公司，但还是第一次见面。意外的发现前面的嘉宾里面有 LVS 的创始人章文嵩博士，失敬失敬。上一届章博士有个主题分享来着。这次简单的交流一会儿，很多细节都讲的比较清楚。

听了一些其它朋友的简单反馈，关于下午各个场次内的演讲情况：有些名气大的人不一定口才好，口才好不一定技术讲的清楚。

晚上阿里巴巴 DBA 大聚会，将近 30 人，IT168 的熊老师买单(据说他们刚收购了 ChinaUnix)，想起来，其实 DBA 们好久没聚在一起了。吃过饭，回家的路上觉得好累。

--EOF--

最近 PHP-FPM (PHP FastCGI Process Manager) 这个话题在讨论组里很受关注。使用 PHP 的朋友对于 FastCGI 进程的管理估计都很头疼，比如 Nginx 下的 FastCGI 就有不少人用的 Lighttpd 的 spawn-fcgi 来对进程进行管理。但这样存在不少缺点(中文版本)。

PHP-FPM 配置起来很简单，但有一点比较有意思的是如何确定 Worker 的数量。PHP-FPM 作者 Andrei Nigmatulin 在新闻组里提到的小技巧如下：

1) 用 Linux top 命令观察 (这个方式比较土)
2) 用 'netstat -np | grep 127.0.0.1:9000' 收集数据。
设置  php-fpm.conf 中的 max_children 的数值使 等待的数量变为最小。

目前使用 PHP-FPM 还只是通过 Patch 方式，然后编译，期待能够早点并入正式的 PHP 代码中。当然，PHP 核心开发的那些大爷们也不知都在忙什么呢，莫非还在为 Unicode 较劲呢?

--EOF--

Tips : PHP-FPM on highload tips

后天，第二届中国网络工程师侠客行大会就召开了。届时，会有来自 Google、微软、雅虎的顶级专家进行技术分享。

Web 2.0 元素

和上次预告除了与会嘉宾稍稍有点出入的是，Yahoo! 旗下的 Flickr 这次会派出 John Thrall 进行题为 Flickr Architecture 的技术演讲。MySQL AB 公司创始人与 CTO David Axmark 将在上午有 Keynote。另外，下午还有 David Recordon 带来的 OpenID 话题。应该说这次会议也充满了 Web 2.0 技术元素的(其实个人觉得开放平台/SaaS 才是重点)。

关于门票

大侠风尚、Single Party

下午听完讲座后，可以用门票换取晚上的 大侠风尚和 Single Party 的门票。或许有朋友能结成良缘也说不定的:)

小广告: 支付宝招聘

支付宝技术部近期在招聘。网站上有相对具体的 招聘要求，我们这边目前对架构师和 DBA 还是比较缺的。感兴趣的，联系我。

--EOF--

杭州最近很多街道两旁的楼面都在装修 ，由政府出钱把临街的居民楼墙体重新装修一遍，象杭州这样爱 "面子" 的城市还是少见的，即使是旅游城市。不过，就在城区大兴"整容"的时候，在杭州武林路商业区核心地带却有这样一栋楼：

这个楼是灯芯巷 32 号，那天路过的时候，和老婆一起拍照，正好出来一位年过花甲的大妈，聊了一会儿，知道了另外一个故事版本，和上面链接中描述的版本有些出入。

不管怎么样，这就是杭州。

--EOF--

偶然发现 Nginx 稳定版本更新到了 0.6.31，这个版本修正的第一个 Bug 值得注意：

Nginx did not process FastCGI response if header was at the end of FastCGI record 

现在国内 Nginx 的用户越来越多了，多数拥抱 Nginx 的网站都钟意其优异的性能表现，如果是相对比较大的网站，节约下来的服务器成本无疑是客观的。而有些小型网站往往服务器不多，如果采用 Apache 这类传统 Web 服务器，似乎也还能撑过去。但个人觉得有其很明显的弊端： Apache 在处理流量爆发的时候(比如爬虫或者是 Digg 效应) 很容易过载，这样的情况下采用 Nginx 不失为大胆而有效的尝试。

当前 Ngnix 美中不足之处是相关的文档和用户经验都还是很欠缺，用户之间还很难做到可借鉴性的交流。

最近因为朋友遇到一些技术问题，我也翻阅了不少 Nginx 的邮件列表内容，发现大量的技术细节仍然在频繁变化中，可是中文社区内相关的记录和讨论太少了。相信国内这些 Nginx 用户积攒的经验肯定是不少的，但可能是因为某些其它因素考虑而看不到相关的技术分享。

当期待大家都做某件事情的时候，最好从自己做起。现在开始尝试收集 Nginx 的相关技术细节......

--EOF--

小发现，网易新闻用的是 nginx/0.5.36

• Nginx实践1 利用proxy_store实现高效的静态文件分布缓存服务器

关于地震的消息越来越密集，相信很多人的心里都是难以平静的。在这样的大灾难面前，远在千里之外的我们，求全责备于事无补，能够做的事情恐怕也就是捐款最为有效的了。我想，很多人对捐款还是顾虑重重的， 总担心自己捐的款被中饱私囊，或是担心自己的捐款又被建成了豆腐渣学校。其实就像我今天 Twitter 上说的一句话: 别去想太多了！ 你对灾区做的事儿不过是让你心里更加平静罢了。

推荐两个对于常在网上逛的朋友比较有效的捐款通道：

淘宝网联手壹基金的捐款活动

这个快速捐款通道目前已经募集了将近 500 万人民币，这是网友的集体力量。相信这个独立运作的壹基金(而不是红十字会"，大家多少还是能信得过的。

牛博的捐款活动

不含任何官方色彩的民间活动。出于大家都知道的原因，我相信同样也会有很多人更为相信牛博(牛博捐款活动地址)。

这两个捐款通道中，支付宝都是主要的方式。一是方便快捷。总不能为了捐款在跑到银行等个半小时吧? 大家都有自己的工作，关心灾区，同时也要节省更多的时间做好手头的工作。 二是不收取手续费。哪怕是 2 块钱的手续费，也能为灾区人民买瓶矿泉水的，节省一点是一点。节省时间，节省成本。

这是 Blog 作者完全个人化的推荐，请朋友们不要和其它因素联系在一起。捐款这个事情，不能攀比，不能苛求别人，对得起自己的内心就足够了。

--EOF--

再推荐一个捐款通道：《读库》创建者老六组织的造屋工程。我相信老六!

在修改后的 《闲谈 Web 图片服务器》 一文中也提及了"IE 浏览器的连接数问题"，这也是个有趣的话题。值得补充记录一下。

这个数据来自 Roundup on Parallel Connections ，这是一篇好贴，里面的每个线索几乎都值得一读(Opera 9 的连接数我做了修改)。以前经常看到某些优化 IE 或者优化 Firefox 的插件或工具，其工作原理也不过是针对这些相关的网络参数合理组合罢了。 好多朋友说 Opera 快，其实可能就是压缩和连接数两个做的更适合现在的网络吧。我不太相信内置解析器什么的真能比其它浏览器有什么质的领先。

其中 Firefox 3 的连接数目前还处于不确定中。对于网站维护人员，这是个非常值得重视的信息，我们总说蝴蝶效应，这恐怕就是最直接的例子了。一旦 IE 8 确定了新的默认连接数，并且短期内大量用户下载，有些网站如果不做调整的话，很可能会被击垮。

--EOF--

对这篇《闲谈 Web 图片服务器》做了补充修正之后，在本期的《程序员》杂志上发表了。不过有朋友提出了一个问题：为什么说 Squid 不适合用 RAID 5　?

大家都知道 RAID 在写性能上因为存在校验，这句话的主要意思还是 Squid Cache 盘/ Cache 目录的问题(而不是放置图片的 RAID 5 磁盘)，在 Squid 满了的情况下，如果占用 Cache 盘，这个盘如果是 RAID 5 ，那肯定性能糟糕的一塌糊涂。另外一个原因是这部分其实不需要 RAID 来提高可靠性的，坏了完全可以 重新构建即可。

可惜我手边没有 Squid 服务器，要不倒是可以用数据来说话的。

参考文档: （一）、 （二），这两个参考信息其实比较旧的了

--EOF--

明天结婚。是阿里巴巴集团同事的集体婚礼。

和老婆风风雨雨一路走来。大学最后一年相识，毕业后，她在青岛，我在北京。她抛弃很好的工作背景，杀到北京，在北京生活三年，又和我一起来到杭州发展。感激老婆，每次虽然面对的不是什么大决择，也需要很大的勇气，想起来多不容易。这期间尤其令我感到内疚的是在北京期间老婆压力过大导致生病，深深自责。

不管怎么样，祝福我们吧! 我先祝福一下 :)

--EOF--

BTW,我的支付宝账户: [email protected]

支付宝主办的阿里巴巴集团 2008 年度 "D4" 设计论坛将于 5 月 8 日举行。大家比较熟悉的刚刚落幕的 D2 技术论坛 是面向 Web 前端技术的，而 D4 则是面向设计(Design)的。

本届"D4" 设两个分论坛：

• 论坛一：交互设计的流程探讨
• 论坛二：如何通过用户研究来提升产品设计

每个分论坛将有阿里巴巴集团各子公司的嘉宾与大家共同探讨各自的主题。

分论坛一：交互设计的流程探讨

时间：2008年5月8日 19：00 －21：00
地点：华星时代广场 5F 天沐阁
嘉宾：李坏（淘宝）、蚂蚁（口碑）、方一鸣（阿里巴巴国际站）、陈晓华（阿里软件）

分论坛二：如何通过用户研究来提升产品设计

时间：2008年 5 月 8 日 19:00 －21:00
地点：华星时代广场 21F 应天书院
嘉宾：轻候（淘宝）、 杨昌源（阿里巴巴国际站）、刘昊（阿里巴巴中文站）

主办方：支付宝
协办方：阿里巴巴B2B，淘宝，阿里软件，阿里妈妈，口碑，中国雅虎

感兴趣的朋友请提前联系一下我，因为场地的确有限制。会议是免费的，华星时代广场就在西湖区文三路和万塘路交汇处。

--EOF--

报名需要的信息：请邮件给我([email protected]) 写一下您的姓名，公司，联系电话，想参加的场次。建议光临的时候有名片的不妨带上，便于交流。

Updated 请注意：名额已满，不接受报名了。敬请见谅！

今天发现 洪启 也写 BLOG 的，并且还在最新的帖子里引用了一张我拍的图片。

非常可惜的是，错过了洪启 3 号晚上在杭州旅行者酒吧的"城市故事"巡演，事先并不知道，要不三号正好购物结束去看。如果 2 号他演出结束的时候小小的预告一下就好了。音乐节现场没有他的专辑卖，过几天到卓越上定购他的专辑(现在缺货)，尽管我已经在网上先下载了 MP3 。关于他的音乐，网上的评论已经很多很精彩了，不多言，咱听就是了。

不知道另外几位几位歌手是否写 BLOG(最好别是别人捉刀) ... 再贴两张演出照片：

阳光太强了，拍的效果不好的照片都是我拍的，效果好的是 Laura 拍的 :) 。(如果看不到 我的 Flickr 相册的内容，请稍晚一点到我的 Yupoo 相册看一下)。

--EOF--

{ZHUAXIA399b3bd3f2b646ffc16b7d29595ac499Union}

五月三日，杭州下午，我好不容易找到了一辆出租车去音乐节现场，窗外是这个城市五月典型的炙热天气。三五成群的面带汗渍的年轻人，也正在这个时候从这座优美的城市四面八方赶过来，所有人的暗号只有一句：音乐节。这似乎表明这座著名的南方旅游城市已是新的小资聚集的重镇。(以上模仿许知远体。而更多小资文可以到叶蓓的百度贴吧找找。)

热，真热，地面温度估计要超过三十五度。而举办方那些孙子把围栏看得更紧了。所以下午大家只能在凳子上作者或者站着--到处都是遮阳伞。

苏阳

很显然的一个错误是苏阳不应该下午第一个出场，现场太火爆了（苏阳干脆号召大家站起来把汗出透好了），以致于每个观众都汗流浃背。也让人担心后面的歌手怎么搞。西北民歌总给人很带劲儿的感觉。我旁边的一个哥们儿对他女朋友说，"听完这个，你听其它的歌都觉得软绵绵"。

偶尔能听明白苏阳的一两句歌词，很容易引人发笑：

李大爷的学习吗真正的强呀
上了一个大学吗上中专 哎嗨咿呀咿得儿喂 哎嗨咿呀咿得儿喂
中专里面学的是---蹦、擦、擦！

买了他的一张专辑，RMB 45，现场附送签名。顺便买了一张万晓利的专辑，也有签名。

写这篇东西的时候正好在听苏阳的这张《贤良》，个人还是喜欢现场的粗糙。录到唱片内的东西总感觉太精细了。

李志

李志出来唱第一句，我和老婆就都觉得不太喜欢，太抒情了。跑后边树荫下歇着去了。隐约中听见李志说到在杭州创作的几首歌。印象最深的是《这个世界会好吗?》台下反应还是挺激烈的。李志的每首歌结束的时候都非常干脆，我还以为被主办方把声音关了呢。

如果要我说李志的音乐分类，"知识分子民谣"。

这会儿我总算借到一张工作证，混到后边拍了不少照片，虎子、万晓利、龙隆、马条，居然还有郝菲尔。

马条

明显的新疆音乐元素，可能是过去根本没听过马条的东西的缘故吧。有些听不进去，是这会儿天阴凉快下来的缘故? 观众也都开始老老实实坐在位置上了，前几首歌气氛都很一般。歌词也听不清楚，或许是他的音乐适合听 CD 。

马条挺瘦。

万晓利

穿着海魂衫的万晓利上场了，现场他的话不多。在这次《官方会刊》里说万晓利喜欢听"罂粟青年"(编辑也太不小心了，"音速青年"嘛!) 这样比较吵的音乐，不过现场的万晓利的音乐还是不算吵的，在《流氓》这首歌里时不时的抖出点"包袱"，大家笑翻。

下午场看完，夜场剩下的几位实在没啥意思，估计又和昨天晚上的口水歌联唱差不多，把票卖掉打道回府。

--EOF--

下午叶蓓还没唱完的时候我就和老婆准备出去吃饭了。走到后面发现姜昕和几个人在那儿聊天呢。

夜场快开始的时候才吃完回来。进场之后估计很多下午就在的人会骂一声：场地周围被栏杆围起来了，下午那样席地而坐的场景是不可能的。多了很多保安，挤到前面拍照也动不动被保安赶到后面去。

小娟

有了下午的王娟，这个小娟的出现多少有些审美疲劳，王洛宾的《永隔一江水》，她又唱了一遍，下午周云蓬已经唱过了。小娟莫明其妙的话也比较多，不过似乎"杭州人民"比较喜欢小娟，说她这是"天籁"，是的，现在满大街都天籁。唱《红布绿花朵》的时候，很多观众都能跟着唱出来，这首歌我还是比较喜欢的，琅琅上口嘛，说明我还是属于外行看热闹这一伙的。

晚上上座率比下午多很多。大部分人都在座位上。我后面的一位大叔，几乎什么歌都能跟着哼哼唱出来，声音还很大，有些扰民。而我左边的一个哥们儿明显是过于亢奋，即使是遇到慢歌，也能在那里摇晃不停，很容易"被感动"。让我对自己比较产生了极大的怀疑。

甜蜜的孩子

这个是从杭州走出去的乐队，据说是什么"中国的 R.E.M" ，音乐很垃圾，基本都是无病呻吟型的歌词。主唱在台上挺卖力，就是听不清唱什么，只记得有首歌名叫做《忆江南》，除此之外能有点印象的是古筝弄的蛮新奇的。

估计是沾了本土作战的光，居然还有人喊着再来一首，他们就真的不客气，再来一首...

韩真真

说老实话，我个人对选秀歌手带点先入为主的偏见的。韩真真上来是自弹自唱，而且和大家解释说这次这么多歌手就她一个傻乎乎的来没有带来乐队。看得出来，舞台经验没别人那么丰富，但是挺真诚的。比刚才那个自我感觉良好的乐队更容易让人接受一些。最后一首歌是自己创作的《香草》，龙隆(鲍家街43号的那个龙隆)临时助阵，做这首歌的主音吉他，效果不错。

估计《香草》未必是最后一首歌的，可惜这时候主持人直接插话进来，说欢迎下一个歌手。你大爷的，这不是欺负人嘛? 超女怎么啦 ? 人这不唱的也不错嘛?

姜昕

一上来，姜昕先说了一下他们是姜昕与超级猴子乐队，好多人都觉得这个名字挺好玩、好笑。第一首歌选的似乎不太好，很难调动情绪，后面的几首也都是口水歌，这东西是民谣么? 你说它是，就是了。乐队...声很大。观众们似乎都看(听)得很"高"，看得出，姜昕虽然小众，但拥趸还是不少的。

一个非常有趣的插曲是姜昕介绍乐队鼓手的时候，台下 N 多人居然傻乎乎的喊"窦唯"，笑倒，就是姜昕的老公三儿来也不可能是窦唯啊。

组后一首歌也是主办方主持人"紧急叫停"的，明显看出来，台上的主音吉他有些困惑--没声音了。不过散了也好。

和下午场相比，晚上的水平差了一大截子。

--EOF--

下午好不容易打到车杀到音乐节现场。天可真热，晒得头晕，幸亏带了把伞过去。

洪启

第一位出场的是洪启。他在唱《美》之前说的话很有意思: "西湖很美丽，全世界人都知道，可在西湖边盖高楼就不美丽了。" 以前几乎没怎么听过他的歌，只知道他是个民谣诗人。他的那首《阿里木江，你在哪里?》让人感动，相信现场的人会对新疆小偷善意一点，问问他是不是叫做阿里木江。

虎子+王娟

在这次活动的《官方会刊》上，是王娟+虎子，实际上，还是虎子+王娟，音乐基本上是虎子主导，当然，王娟的演唱也的确是有特点。这也是今天现场效果最好的表演，好极了，相比之下，晚上的所谓腕儿都是狗屁。《爱情国度》、《六一》在现场都引起了不小的轰动，新歌《探戈》我也很喜欢，准备找一下他们的新专辑。

虎子的舞台动作看起来挺好玩的，很电子。

周云蓬

坦白的说，或许出于某种原因，今天周云蓬的演唱并不是最好的状态。演唱《买房子》的时候，可能是太能引起现场听众的共鸣，现场的观众几乎都会心一笑。虽然大家一再要求唱《中国孩子》，可最后只是用一首《沉默如迷的呼吸》作为结尾。

跑到后台去拍他的照片，问了一下他是主办方不让唱《中国孩子》么? "对，不让。公安局长在那边呢。" 要买他一张专辑，找不开钱，干脆一起买了三张。然后还跑到人堆里给他免费广告了一下。

对了，另外一件事：周云蓬经常上豆瓣他的小组更新信息的。

叶蓓

给周云蓬拍照的时候，刚好看到了叶蓓，拍照的时候很善意的配合。接下来，她就上场了。乐队开场演奏的不错，叶蓓的舞台范儿也不错，可就是歌听起来不那么...和老狼合唱的《在劫难逃》还是让在场的人蛮激动的。

到了这会儿，感觉实在没意思，有些饿了，和老婆跑出场外找地方吃饭去了。

下午大家基本上是随便坐的，好多人都坐在舞台下的草坪上。现场人不多，保安也不怎么管。这种随意很好。

(更多照片稍晚一点到我的 Yupoo 上看吧)

--EOF--

好多 Windows 平台的 DBA 一定比较烦操作系统升级时 "重启动才能生效" 这个问题，可能就是因为这个原因，可能没多少人愿意管理 Windows 平台的数据库。其实 Linux 有的时候也有类似的毛病，对 Kernel 打 Patch 基本也要重启动操作系统，除非你不去理它。而最近 Slashdot 一则关于 Linux 的新闻值得关注， Ksplice: Rebootless Linux kernel security updates，对于非常关注系统可用性的 DBA 来说，这是个很关键的技术改进。

提高可用性技术，前期细致周密的规划是重要一环。比如大文件系统的 fsck 问题，默认情况下达到一定 mount 次数或者超过一定时间，系统会自动启动 fsck 检验操作。而一个运行一段时间的 Linux Server 如果崩溃 reboot 后，文件系统校验时间漫长的叫人绝望。如果最初对这个问题进行预处理，即可避免不必要的停机时间。

另外维护中能尽量积累那些"可用性高"的技术或技巧也是必不可少的。比如 Kernel 重新读取分区表的问题，Fdisk 命令是搞不定的，而这里提到的 partprobe 命令 刚好派上用场。

以前我也记录过类似 Linux 如何不重启而识别新增的 LUN 的话题，积少成多，也就有用了。

--EOF--

Updated:

• Linux 的 Out-of-Memory Killer