这两天 Firefox 突然变态，时不时的占用接近 50% CPU 资源，带来的现象是系统应用程序响应极慢。开始还以为是个别页面带来的问题，后来发现原来是普遍现象。这类问题开始不好求助于 Google ，说实话，不知道用啥作关键字搜索。
忍无可忍，赶紧调用 Process Explorer ，发现单个 PID 占用大量的 CPU 上下文交换资源，如图：
看了一下，不知道 “jpeg_free_large” 是干啥的，遂用 “Firefox jpeg_free_large” Google 一下，出来的一堆东西里有帖子说可能和 Apple 的 QuickTime 插件有关。我也不知道如何删除该插件，到 Firefox 安装目录下的 Plugins 里看了一下，还真有一堆文件是 QuickTime 相关的插件，版本号不同而有不同的文件。
删掉。重启动 Firefox ，OK。
这个问题估计对于使用了 iPhone 的用户比较容易中招。
–EOF–
虽然奋斗多年，依然是无产者一个。最近据说杭州的房价在飈涨之后终于有点一点点回落，也感觉总不买也不是那么回事(如果全国人民都不买可能还有点用)，再这样下去人家都不愿意嫁给我了。去年上半年其实倒是可以买的。只是那段时间忙于工作，等清醒过来发现房价已经高不可攀了。谁让我总是后知后觉呢。
周末联系了几家中介，然后随同老婆大人看看杭州城西的二手房子。
从现在住的小区出去，向西，平均不到 10 米就能看到家房地产中介。在房源比较集中的几个小区门口，三三两两的路人口中谈论的几乎都是关于房子的事情，正所谓，”十亿人民九亿炒房，还有一亿中间商”。有的时候一个房源几乎几拨人马一起杀到。
周五晚上到今天下午，一共看了五处，在各个小区间转悠，上楼下楼，腿肚子转筋。老实说，按照现在的建筑质量，98 年以前的房子基本都破得不太像样子了，但价格可都不低。破破烂烂的也都 15K 起，好一点的小区，基本有钱也没人卖，当然我也没那么多钱买。
接下来有时间准备去滨江看看，滨江最大的麻烦倒不是上班路远，而是很多小区空置率太高–即使你住进去了，装修噪音总要忍受的。每新搬进来一家，装修总要持续一个月吧，那些空房大都是有钱人买来投资的，什么时候出手还都不一定呢。可以想见那些已经住进去在未来的几年中在家里就要时不时的听电锯声了。
谨以一首周云蓬的《买房子》送给天下同样可怜的人：
买房子
买了一套房子，花了三十多万，买房子的钱，全靠银行贷款
从今天以后，不能随便请客吃饭了，不能多喝酒，不能去旅游
从今天以后，我要去上班了，我要努力地还钱，我要还清贷款
不管风雨雷电，我要去上班，不管天塌地陷，我要去上班
不管洪水滔天，我要去上班，不管海枯石烂，我还是要上班
我努力地还，我拼命地还，我要一直还钱，我要还清这贷款
直到有一天，所有的钱都还完了，头发也就白了，嘴里没有牙了
(唯一需要更改的是, “三十多万”, 现在在一般的中型城市买房子恐怕也有些吃力了)
–EOF–
这两天关注了一下基于 SAN/NAS 的集群文件系统的产品。找到了关于 Alexa 的一则旧闻，之后又发现了一篇关于 AOL 部署 SAN 文件系统的文章。
Alexa 超过 1000 台 Linux 服务器 Farm，每半年增长 300T 新数据。经过了同类产品的选型后，最后选择了 Ibrix 融合文件系统。
SAN 使用的是 HP Modular Smart Array (MSA1000) ，最大支持 12T ，Cache I/O 最大 3 万个，算是个中低端的阵列。Amazon 没有透漏这套系统的吞吐能力，只是说 Ibrix 这套系统能达到 1T 的 I/O 聚合能力，单个 NameSpace 可达 16PB 容量。
不过从现在的一些迹象上来看，Amazon 对存储层重新做了改造。这套解决方案被替换掉了也说不定.
原有状况：3000 台主机通过 10000 多个光纤通道端口连接到传统的 SAN 上。其中有 8PB 的非结构化数据，分布在大约 1000 台 文件服务器上。管理维护的复杂度可想而知。
解决方案：文件服务器采用直连的磁盘，每个 12 块 700GB 的 ATA 磁盘，然后通过 Ibrix 融合文件系统进行集群化。
看起来，Ibrix 提供的解决方案很有竞争力。现在一些比较大的用户对于存储层的集群的需求越来越多，快成为趋势，一揽子解决方案还是有必要的，毕竟不是每家技术能力都强如 Amazon、Google ，有的时候用第三方的成本是能小于自己动手 DIY 的。
–EOF–