今天看到 Brad Fitzpatrick (就是大名鼎鼎的 Memcached 的作者，现在效力 Google) 在网志中说道，正在利用 Google 著名的 20% 的业余时间为 Google App Engine 增加对 Perl 的支持。
[来源]
还记得时不时的会从中文 Perl 邮件列表里看到有人散布 Perl 过时的言论，其实一个语言过时与否都不重要，关键的是是否有人依赖该语言打造出比较激动人心的应用。如果 GAE 能够支持 Perl ，或许就是 Perl 焕发第二春的时候。从这个角度来说， Erlang 不也是如此么?
--EOF--
]]>谁知道 Sun 葫芦里卖的什么药，看家宝 Java 都开源了，在 MySQL 上还保留什么呢? 能否成为更受人尊敬的公司，还要看气度。这点上，Sun 始终扭扭捏捏。
一心要做 Web 2.0 中的这个 Dot 的 Sun，看来又要做活雷锋了，不过这次似乎是要帮助一下竞争对手 PostgreSQL。
--EOF--
]]>这个特性应该重点针对 PHP 应用的。PHP 不支持真正的多线程，非持久连接非常消耗 CPU 资源，扩展性也差；持久连接扩展性好了一点，但是又额外占用更多的内存资源(PHP 之父在几年前的一个 Step-by-Step 优化演示的文章中很形象的说明了连接开销对应用的影响)。DRCP 的出现能更好的缓解上述两个问题，其共享连接能跨 Apache 与中间件节点，但共享的连接是基于数据库用户的，比如 Scott 用户登录到 DB 上的所有连接间共享。
Oracle 官方披露的测试数据是，在 4 CPU Intel Xeon MP 2.80GHz 机器上，2GB RAM, 32bit RHEL 4. 支撑到 14000 个链接的时候，CPU 使用率在 65% 左右。这个...还是太惊人了，根据我找到的另外一份测试结果，看来要大打折扣才能有参考性。
--EOF--
]]>
这个插件几乎能搞定 Nagios Alert检查的方方面面，具备足够丰富的的过滤规则与显示条件；还能够定期调度；有趣的是，居然还提供声音报警。
一般人我不告诉他！
--EOF--
这两个软件，应该都是从实际应用需求上得来的，可以说是”设计以致用“，不是纯用于研究的，而设计思路很有些 "Mashup"。我没有实际使用经验，不知 Memcachedb 和 Tugela Cache 二者有何差别。我对 Memcachedb 这个项目倒是比较感兴趣的，把 Cache 和 DB 有效结合起来，消除 DB 单点 I/O 承受的应用压力...而且，实现方便且廉价...十分美好的前景。
期待能有更多类似的项目涌现出来。国内的 Web 2.0 站点软件设计人员也可以借鉴一下。
--EOF--
更新：【很多人估计从来不仔细看文章的具体内容。我这篇文章里可看不出来 ”对Memcachedb的思想比较推崇“的, TBStore 也未必就有多超前，内存 + DB 八百年前就有人想到了。只是赞扬一下 Sina 团队的精神而已，如果只是攀比牛B，去和Google 、eBay 比比好了】
]]>
Yahoo! 和 Carnegie Mellon 大学合作的开源分布式计算项目代号为 M45，这个 超级计算集群 有 4000 个处理器，3T 内存，1.5 PB 存储空间，自称足以跻身世界超级计算机 50 强。这两天网络上搜索最火的一个词应该就是 Hadoop 了吧? 雅虎的这套集群就是跑在 Hadoop 上。
Hadoop 现在已经有很多不错的应用案例可以参考，比如这篇 Running Hadoop MapReduce on Amazon EC2 and Amazon S3
Yahoo! 或许早意识到自己的 Web 1.0 方式下的计算能力比 Google 差的太远，干脆放手一博，助力 Hadoop 项目，期望能借助开源的力量与 Google 掰一下手腕。从这里我们得知 Yahoo! Hadoop 团队早在 06 年就成立了，当然，这个团队成立的前提是 Doug Cutting 入职雅虎。
雅虎现在不应该担心追不上 Google ，应该担心 Doug Cutting 别被 Google 挖去，否则，可真的没机会了。
--EOF--
来点直接的数据：
架构示意图如下：
Copy @Mark Bergsma
在我写的这些网站架构的 Blog 中，GeoDNS 第一次出现，这东西是啥? "A 40-line patch for BIND to add geographical filters support to the existent views in BIND", 把用户带到最近的服务器。GeoDNS 在 WikiPedia 架构中担当重任当然是由 WikiPedia 的内容性质决定的--面向各个国家，各个地域。
WikiPedia 用 LVS 做负载均衡, 是章文嵩博士发起的项目,也算中国人为数不多的在开源领域的骄傲啦。LVS 维护的一个老问题就是监控了，维基百科的技术人员用的是 pybal.
Lighttpd 现在成了准标准图片服务器配置了。不多说。
维基百科网站成功的第一关键要素就是 Cache 了。CDN(其实也算是 Cache) 做内容分发到不同的大洲、Squid 作为反向代理. 数据库 Cache 用 Memcached，30 台，每台 2G 。对所有可能的数据尽可能的Cache，但他们也提醒了 Cache 的开销并非永远都是最小的，尽可能使用，但不能过度使用。
MediaWiki 用的DB 是 MySQL. MySQL 在 Web 2.0 技术上的常见的一些扩展方案他们也在使用。 复制、读写分离......应用在 DB 上的负载均衡通过 LoadBalancer.php 来做到的，可以给我们一个很好的参考。
运营这样的站点，WikiPedia 每年的开支是 200 万美元，技术人员只有 6 个，惊人的高效。
参考文档：
Wikimedia architecture （PDF)
Todd Hoff 的文章
--EOF--
]]>存储厂商 EMC 也有个 EMCgrab 工具，工作原理类似，额外抓取了存储相关的信息而已。估计各家存储厂商都有，要不远程支持也太费劲了。
--EOF--
]]>Kyle Cordes 对这个视频中的内容做了介绍。里面有不少技术性的内容。值得分享一下。(Kyle Cordes 的介绍是本文的主要来源)
简单的说 YouTube 的数据流量, "一天的YouTube流量相当于发送750亿封电子邮件.", 2006 年中就有消息说每日 PV 超过 1 亿,现在? 更夸张了,"每天有10亿次下载以及6,5000次上传", 真假姑且不论, 的确是超乎寻常的海量. 国内的互联网应用,但从数据量来看,怕是只有 51.com 有这个规模. 但技术上和 YouTube 就没法子比了.
YouTube 出于开发速度的考虑，大部分代码都是 Python 开发的。Web 服务器有部分是 Apache， 用 FastCGI 模式。对于视频内容则用 Lighttpd 。据我所知，MySpace 也有部分服务器用 Lighttpd ，但量不大。YouTube 是 Lighttpd 最成功的案例。(国内用 Lighttpd 站点不多，豆瓣用的比较舒服。by Fenng)
视频的缩略图(Thumbnails)给服务器带来了很大的挑战。每个视频平均有4个缩略图，而每个 Web 页面上更是有多个，每秒钟因为这个带来的磁盘 IO 请求太大。YouTube 技术人员启用了单独的服务器群组来承担这个压力，并且针对 Cache 和 OS 做了部分优化。另一方面，缩略图请求的压力导致 Lighttpd 性能下降。通过 Hack Lighttpd 增加更多的 worker 线程很大程度解决了问题。而最新的解决方案是起用了 Google 的 BigTable， 这下子从性能、容错、缓存上都有更好表现。看人家这收购的，好钢用在了刀刃上。
出于冗余的考虑，每个视频文件放在一组迷你 Cluster 上，所谓 "迷你 Cluster" 就是一组具有相同内容的服务器。最火的视频放在 CDN 上，这样自己的服务器只需要承担一些"漏网"的随即访问即可。YouTube 使用简单、廉价、通用的硬件，这一点和 Google 风格倒是一致。至于维护手段，也都是常见的工具，如 rsync, SSH 等，只不过人家更手熟罢了。
YouTube 用 MySQL 存储元数据--用户信息、视频信息什么的。数据库服务器曾经一度遇到 SWAP 颠簸的问题，解决办法是删掉了 SWAP 分区! 管用。
最初的 DB 只有 10 块硬盘，RAID 10 ，后来追加了一组 RAID 1。够省的。这一波 Web 2.0 公司很少有用 Oracle 的(我知道的只有 Bebo,参见这里). 在扩展性方面，路线也是和其他站点类似，复制，分散 IO。最终的解决之道是"分区",这个不是数据库层面的表分区，而是业务层面的分区(在用户名字或者 ID 上做文章,应用程序控制查找机制)
YouTube 也用 Memcached.
很想了解一下国内 Web 2.0 网站的数据信息,有谁可以提供一点 ?
--EOF--
]]>五月份阿里巴巴举办的侠客行网络大会 Cal Henderson 因为时间的关系而没能成行，希望这次的采访能弥补一下不少人的遗憾。
--EOF--
]]>前文说过超级块的位置，对于一个未知的 Ext3 文件系统，也可以用 fsck 模拟对设备的格式化，输出的内容中会列出 Superblock 的位置。命令开关是 "-N".
Testdisk是一款超强的开源文件系统恢复工具，通过它也很容易检查到超级块的信息以及如何恢复，很关键的一点是，这个工具能检查到"可用"的超级块信息
有的时候，也有可能是分区表信息损坏。fdisk -l /dev/hdx 会提示该设备上没有任何分区信息。gpart 这个小工具恢复分区表比较有效。当然，前面介绍的 Testdisk 也能做到这一点，如果该设备上只有一个文件系统，那么直接 fdisk 处理一下也是可行的。
Linux / Unix 没有 Windows 回收站这个概念，rm -rf 有的时候会造成一定的灾难。个别的时候，e2undel 能派上用场。
--EOF--
]]>- Pressing Ctrl+Break now sends a serial break signal in the serial back end, and in the SSH and Telnet backends it asks the server to do the same (if the server supports it). The previous Ctrl+Break behaviour can still be triggered with Ctrl-C.- On Windows, it is no longer necessary to configure high-numbered
serial lines such as COM10 as `\\.\COM10'; PuTTY does this
automatically.- You can now store a host name in the Default Settings.
还有不少 Bug 修订。估计 Putty 在国内网络人员中的普及原不及 SecureCRT。
--EOF--
]]>这是当年我在毕业求职的时候遇到的一个面试题。没有难度。如果说法换一下，"说出 10 个 GNU 核心命令"，即使我能蒙出来 10 个，怕也会有错误。
GNU 核心工具(GNU Core Utilities)指的是 GNU 操作系统基本的文件、Shell、文本维护工具。
The GNU Core Utilities are the basic file, shell and text manipulation utilities of the GNU operating system. These are the core utilities which are expected to exist on every operating system.
GNU 核心工具 包括 fileutils、Shellutils、textutils 三个部分。其中 fileutils 只有 22 个命令，有三个命令我居然从来没有用到过，分别是 mkfifo(Creates FIFOs)、shred(Destroy data in files)、vdir(Long directory listing)。Shellutils 有 35 条命令，其中也有我从来没有注意过的命令，比如 pinky(Lightweight finger)；textutils 工具中也有用的极少的工具，而且用的时候也往往有一些坏习惯，textutils 有 26 条命令，注意 VI/VIM 并不在其中。
初学 Unix/GNU Linux 的时候往往觉得老虎吃天，无从下口。这里有个小小的建议：从这个 GNU 核心工具开始，逐步掌握包含的三类几十条命令。对于类 Unix 操作系统你就可以拿出去蒙人了，呵呵，象 Unix 操作系统速成? 这有点像《天龙八部》中鸠摩智学会了小无相功，就能把少林 72 绝技耍的像模像样有些类似。当然，仅靠这一点还不足以行走江湖，有时间咱再继续说。
--EOF--
]]>我个人最期望的 Tab 功能(以 Tab 形式显示多个会话)没有被加进来。在 Putty 的 Wishlist列表中，很多人也在期待这个功能。如果说同类的商业工具 SecureCRT 还有什么不可替代性的话，可能也只有这个 Tab 功能。在这个请求 Tab 功能 Wishlist 的页面，有人列出了几个解决方案，感兴趣的朋友不妨尝试一下。
基于 Putty 定制的 Pietty 还是老版本(看样子作者是当兵去了，台湾兵役制度也挺烦人的)。对于中文用户，强烈推荐使用! 这个小工具简直太酷了。
提供另外一个信息：如果对 zmodem 传输文件非常依赖的话，尝试一下 Le Putty。如果对 Tab 功能很依赖的话，可以尝试一下 PuttyTabs。
--EOF--
]]>
BitTorrent、Zudeo、Emule(代表站点 VeryCD)、网际快车 Flashget (kuaiche.com)、迅雷 (xunlei.com)这一类软件如果从另一个角度看，不妨都把他们称之为媒体分发工具，现在几乎都在作着同样的动作：构建门户。我们常说内容为王，对于这类的工具，我想最重要的前提是要有一个用户可以获得媒体信息的地方，搜索虽然是一个不错的手段，但是通过 Web 页面 "寻找-->查看-->下载"已经成为很多人的习惯，所以现在几个工具都在做的门户，或者进一步说多媒体门户。
如果观察一下这几个站点，网站内容的形式很类似：搜索框 + 媒体内容导航。当然也有差异，比如中文站点页面都非常的冗长，包含大量的盗版内容。这些网站都够 2.0 么? 很难说，1.75 还凑合 :) 很难一眼看出那些是用户贡献的内容，哪些是编辑的拷贝粘贴。我倒是期待能有这样的站点：用户贡献内容+用户评价内容(获得高评价的用户应该有获得一定收益的可能)。这两条腿都能走路的话，交互性更大。
不管怎么说，此类门户站点机会不小，我们拭目以待。
--EOF--
]]>