从 Flickr 的 DB 服务器配置说起 Swap
来源:互联网 发布:angus young知乎 编辑:程序博客网 时间:2024/05/17 06:32
又读了一遍这个 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--
Generator | Trampoline | 外贸英才网 | Vinyl fence
本文相关评论|Comments(4)
- 从 Flickr 的 DB 服务器配置说起 Swap
- 从 Flickr 的 DB 服务器配置说起 Swap
- 从Tomcat服务器的日志说起
- 从服务器构建说起(四).Linux下安装配置Oracle
- 从服务器构建说起(四).Linux下安装配置Oracle
- 图解Flickr的服务器架构
- 从DDOS说起:最优的服务器集群方案-PaceMaker
- PHPUnit从零开始(1):从它的安装配置说起
- 从服务器构建说起(二).磁盘阵列RAID
- 从普林斯顿的宽容说起
- 从北京的四合院说起
- 从js的dtree说起
- 从香蕉的果蝇说起
- 从 grep 的用法说起
- 从自己的电脑说起
- 从OpenCV2的Mat说起
- 从Java的Collection说起
- MySQL服务器Swap满了100%导致db很慢很卡
- 收集网文:对 window.execScript(sExpression, sLanguage) 探究
- 批量消除超链接虚线框 onfocus=”this.blur()”
- 三位大学生的创业故事
- linux中的pushd命令及栈原理
- 点击超链接调用javascript函数
- 从 Flickr 的 DB 服务器配置说起 Swap
- HR实现虚线效果
- 如何为greasemonkey开发userScript
- 大学生创业故事:短信聊天聊成了心理咨询老板
- vss+eclipse
- SATA硬盘的硬件安装明明白白用SATA硬盘
- Postgre 中的 null 列
- iptables使用
- 两种改变 Windows Vista UI语言的途径
如何高效地运用大量的物理内存,在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 我以前写过很多了,基本上没啥可写的了,再深入的东西人家也不会透露了