又读了一遍这个 PPT： Federation at Flickr: Doing Billions of Queries Per Day ，发现还是值得咀嚼一下，尽管这"甘蔗"已经被吃过了。
针对主机环境的实践参考
Flickr 数据库的硬件配置一般用 16G 内存，6块 15K 硬盘，RAID 10，在 EM64T 下跑 RHEL 4，运行在 Deadline I/O 调度器 模式 。回写 Cache 用控制器电池而不用磁盘的 Cache。Swappiness 设置为 0 . 。
大内存数据库服务器的 Swap 设置问题
上面提到了 Flickr 是把 Swappiness 设置为 0 ，简单的通过:
echo 0 > /proc/sys/vm/swappiness
个别情况下这样也可能没起作用，因为实际上对 Swap 的调用是由如下的公式计算得到的：
swap_tendency = mapped_ratio/2 + distress + vm_swappiness;
其中 vm_swappiness 默认值是 60.
这是个防御性的措施。Linux Kernel 2.6 （个别版本）有些诡异行为，当有大量物理内存空闲的时候，Linux 仍(或许)会傻乎乎的调用 Swap 空间，这导致有的时候系统性能很差。有人建议如果是 INNODB 的引擎的话，可以用 O_DIRECT 的方式强制直接调用物理内存。但似乎副作用很大（存疑)。
如果关闭 Swap (swapoff -a)的话，又会遇到 OOM 的问题。这是绝对不推荐的。
还有人用的方式是把 Swap 建立到 RAM 盘上。
Swap 的自动校正其实是个老问题，几年前可能超过 4g 的 Linux 服务器都不多，而现在动辄几十 G 的内存配置，应用场景发生了很大变化，Kernel 的算法思路肯定也要调整一些了吧(尽管几年来不断看到有小的 Patch 出来，可好像 RHEL 的 Kernel 还是老样子)。
我在这里抛砖引玉，大家实际应用中应该也遇到类似问题吧? 有什么建议? 还是干脆就不管? 默认情况下其实也能跑...
--EOF--
如何高效地运用大量的物理内存，在Windows上也是一个问题。
比如Sql Server，要搞AWE，Lock Pages in Memory等。并且内存大了，运行系统也需用更多的内存来管理，所以还要设置Sql Server可使用内存值的上限等。还有其他林林总总的从32-bit 到 64-bit 的bug，一不小心，就会被咬一口。把这些问题解决，貌似还需要些时间。
对于一台只用 InnoDB 的 MySQL 服务器，O_DIRECT 不会有什么副作用。
如果一个系统真的 OOM 了，那么只有两种可能：一、你给程序分配的内存超过了物理内存的限制；二、由于各种原因（比方说内存泄漏），程序实际使用的内存超过了我们的设计。在第二种情况下，开着 swap 也是没用的，因为该来的还是会来，swap 只不过是让 OOM 来得更晚一些。而且对于很多数据库来说，swap 的性能损失是没有办法接受的，还不如 crash 来得干脆。
不是所有的机器都是服务器，这在 LKML 里应该是一个通用的假设。对于一个执行着很多进程的桌面系统，page cache 在很多时候确实很重要，所以 Linux 宁愿把其它进程换出，也不愿意清 page cache。
我根据http://highscalability.com/flickr-architecture写了篇flickr的架构解析，地址http://chaoqun.17348.com/2008/08/flickr_architecture_part_i/，请批评指正。
@超群
看了，基本上也就是翻译啦。Flickr 我以前写过很多了，基本上没啥可写的了，再深入的东西人家也不会透露了