从 Flickr 的 DB 服务器配置说起 Swap

又读了一遍这个 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


4 thoughts on “从 Flickr 的 DB 服务器配置说起 Swap

  1. 季庄新闻

    如何高效地运用大量的物理内存,在Windows上也是一个问题。
    比如Sql Server,要搞AWE,Lock Pages in Memory等。并且内存大了,运行系统也需用更多的内存来管理,所以还要设置Sql Server可使用内存值的上限等。还有其他林林总总的从32-bit 到 64-bit 的bug,一不小心,就会被咬一口。把这些问题解决,貌似还需要些时间。

    Reply
  2. 0x44

    对于一台只用 InnoDB 的 MySQL 服务器,O_DIRECT 不会有什么副作用。
    如果一个系统真的 OOM 了,那么只有两种可能:一、你给程序分配的内存超过了物理内存的限制;二、由于各种原因(比方说内存泄漏),程序实际使用的内存超过了我们的设计。在第二种情况下,开着 swap 也是没用的,因为该来的还是会来,swap 只不过是让 OOM 来得更晚一些。而且对于很多数据库来说,swap 的性能损失是没有办法接受的,还不如 crash 来得干脆。
    不是所有的机器都是服务器,这在 LKML 里应该是一个通用的假设。对于一个执行着很多进程的桌面系统,page cache 在很多时候确实很重要,所以 Linux 宁愿把其它进程换出,也不愿意清 page cache。

    Reply
  3. 超群.com

    我根据http://highscalability.com/flickr-architecture写了篇flickr的架构解析,地址http://chaoqun.17348.com/2008/08/flickr_architecture_part_i/,请批评指正。

    Reply
  4. Fenng

    @超群
    看了,基本上也就是翻译啦。Flickr 我以前写过很多了,基本上没啥可写的了,再深入的东西人家也不会透露了

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *