又讀了一遍這個 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 還是老樣子)。
我在這裏拋磚引玉，大家實際應用中應該也遇到類似問題吧? 有什麼建議? 還是乾脆就不管? 默認情況下其實也能跑...