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

原贴: http://www.dbanotes.net/arch/flickr_db_swap.html

从 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--

| Permalink | TrackBacks (0) | | Edit

Generator | Trampoline | 外贸英才网 | Vinyl fence

自定义搜索

本文相关评论|Comments(4)

季庄新闻 的评论:

如何高效地运用大量的物理内存,在Windows上也是一个问题。

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

0x44 的评论:

对于一台只用 InnoDB 的 MySQL 服务器,O_DIRECT 不会有什么副作用。

如果一个系统真的 OOM 了,那么只有两种可能:一、你给程序分配的内存超过了物理内存的限制;二、由于各种原因(比方说内存泄漏),程序实际使用的内存超过了我们的设计。在第二种情况下,开着 swap 也是没用的,因为该来的还是会来,swap 只不过是让 OOM 来得更晚一些。而且对于很多数据库来说,swap 的性能损失是没有办法接受的,还不如 crash 来得干脆。

不是所有的机器都是服务器,这在 LKML 里应该是一个通用的假设。对于一个执行着很多进程的桌面系统,page cache 在很多时候确实很重要,所以 Linux 宁愿把其它进程换出,也不愿意清 page cache。

超群.com 的评论:

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

Fenng 的评论:

@超群

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

你可能感兴趣的:(从 Flickr 的 DB 服务器配置说起 Swap)