Tag Archives: Google

Google 使用 Linux 的情况

Google, Inc.

Image via Wikipedia

技术爱好者大多都知道 Google 是使用 Linux 的大户，但是一直以来对于他们如何使用 Linux 却知之甚少，甚至内核开发社区对 Google 内部使用的情况也了解不多。LWN 上的这篇 How Google uses Linux 给我们带来了不少信息。

Google 使用 Linux 肯定有很多令人震惊的地方，第一个令人”惊讶”的是他们使用的代码管理工具：Perforce 。代码维护方式看起来也比较落后，当前维护的代码版本远远落后于开源社区内核版本，因为 Google 自己要维护大量的内部特性，每一个大版本发布周期是大约 18 个月，而内部特性的回归也要折腾6个月。因为版本滞后，所以有不少向后移植(Backporting)的工作要做，这个比例大约是 25%，还是不小的。

Google 内部大约有 30 个内核开发人员，而之所以外界很少看到 Google 对 Linux 的 Patch 代码，主要的原因居然是–担心代码不够优雅。我想这应该说的是大实话。我也遇到过很好的开发者对开源软件做了改进之后不愿意把代码贴出来，原因就是担心代码不好看，怕被笑话。

因为应用程序类型之故，对于 Google 来说，完全公平调度器(Completely Fair Scheduler)并不适合，采用了 O(1) 调度器，一般 16-32 核的机器要跑 5000 个线程左右。

Google 倒是喜欢用 Out-of-memory (OOM) killer 特性，这倒是出乎我的意料。Google 对于内存管理方面的改进或许是不小的突破: 通过伪 NUMA 模式来保证不同类型应用对内存的使用。除此之外，有大量的代码用于系统的监控，针对磁盘、网络等子系统或者是针对应用程序性能。

对于计划中的将实现的新特性，在一堆列表中看到了在 I/O 层对于高速 Flash 盘的支持计划。在文末，另一个有趣的技巧是，Google 喜欢把文件系统的元数据 Pin 到内存里以便提高读取响应时间。

或许将来能看到 Google 为 Linux 内核贡献更多代码，那会是一件很有意义的事情。

–EOF–

关于信息的五分钟问题

最近一直在考虑这个关于信息的”五分钟”的问题。搜索了一下，发现还很少有人考虑这个现象，思路还没有完全理顺，先抛几个观点等待大家的补充吧，期待能引发一些对信息处理的思考。

最早注意到这个现象是每次我 BLOG 更新之后，在大约 5 分钟左右，通过 Google 的 BlogSearch 就可以看到内容。这个倒很容易理解，因为我用的 Movable Type 在发布文章的时候会自动通知一下 Google 服务器。接到通知之后，Google 能够较快的把信息合并(Merge)到当前的索引中，但是应该还没加上非常严格的排序(Sort)，这是个很经典的处理技巧。

不过，Google 获得信息绝大部分是通过爬虫”抓取”，也就是”拉”(Pull)数据，只有少部分是用户”推送”(Push)的。这就导致 Google 在信息处理上节拍总要慢一点。Google 的目标是处理地球上的所有信息，无远弗届，但信息的及时性或许是最难解决的。

而 Facebook / Twitter / FriendFeed 等具备面向”实时信息流”(Real Time Lifestreaming)功能的网络应用，大部分信息都是用户”推送”上来的，所以也有天然的优势触及这五分钟之内的数据，并经过简单的局部计算之后呈现给用户。得到”即时”信息似乎是人的天性（另一个侧面的印证是人们无法摆脱手机而全部使用 IM 和电子邮件），所以五分钟之内的数据处理能力是对普通用户来说有着难以言明的吸引力。

“五分钟”只是个大致的说法，相信随着技术的发展，会缩短到三分钟，乃至更短。但这部分始终是 Google 无法完全覆盖的地方，技术没办法打败时间，这也是信息暗网的也无法解决的问题。最终我们发现，信息处理的巨人和信息处理的快刀手一起相处的比较融洽。

–EOF–

注：很明显，这个”五分钟”问题和我之前说的关于 I/O 的五分钟问题是不搭界的。

Google 对数据中心的影响

传闻 Google 从 Intel 订购芯片，要求更具耐热性，要求 CPU 能在超出标准工作温度 5 摄氏度情况下运行。这样可以大量节省空调制冷带来的电力费用。

最近的另一个消息是 Google 在号召厂商采用 12V 电源的主板。节省功耗。

空间和电力是 IDC 头疼的两个地方，对于节省空间，Google 的服务器设计趋势是在一块主板上设两个服务器 ，有些类似硬件上的虚拟化。

Google 的这些举措其实也是其他上了规模的公司要走的路，肯定也会对 IDC 产生及其深远的影响。昨天和朋友在聊省电的事情，我当时能想到的也就是低功耗硬件, 比如低功耗 CPU、采用SSD、硬盘自动降速等几个有限的方式，倒是没想到更耐热的 CPU 这一点，而面向 IDC 的硬件集成这也是个很好的参考。

参考资料：

–EOF–

Google 的 Deep-Web Crawl

搜索引擎的行为会对网站架构稳定性有影响么? 肯定的。影响都有哪些呢? 且说，Google 的 Jayant Madhavan 在 VLDB 2008 会议上做了题为 Google’s Deep-Web Crawl 的报告。这个报告其实也透漏出了 Google 对一些网站的潜在影响的某个方面。

何为 Deep Web ?

  • HTML 表单后的隐藏内容(表单提交后显示的内容)
  • 通过普通搜索引擎获取不到的内容

Deep Web (译为深层网页?) 目前容量大约有多大? 超过100 亿的不重复表单，而且大量都是结构化数据。对搜索引擎用户来说，这部分潜藏的数据是非常有价值的。Deep Web 包括的信息内容：

  • 信息型表单；
  • 登录表单不要；
  • 交互性表单也有用；

Google 的解决办法是基于信息模板(informative templates)。其实不难理解，这些模板（似乎也叫查询模板, Query Template）是在 Google 进行了大量的数据分析的基础上得出来，然后通过反馈迭代修正，加上Google 引以自豪的算法啦，渐渐的模板就会很好用了。

绝大多数网站表单后面是要有数据库支撑的。Google 自己计算出来的模板实际上会对应被爬行网站的 DB 查询上来(Google 也是黑箱研究嘛)，如果查询模板不是很匹配，或者是 Google 查询的频率过高，相信会对一个被爬行网站的稳定性带来很大冲击。尤其是针对数据库，一时爆发的大量查询引发的高负载可能会让系统撑不住。

–EOF–

更多的时候，搜索引擎带给一个网站的访问压力甚至大于用户带来的压力，所以，设计的时候也应该尽量采取悲观的方式，不能完全期待 Google 以及其他搜索引擎默认行为都是可以承受的。