C/C++程序员应该如何应对OOM？

wwwsq

作为一个C/C++程序员，应该怎么应对OOM，尤其是作为一个linux server开发者？


很多人喜欢逻辑上‘完美’的解决方案，下面两个是常见的：

1，new失败的时候抛异常，外面进行catch和拒绝
2，程序判断malloc/new的返回值，为NULL就拒绝请求


这两个看似完美的方案都有巨大的缺陷。

1，new失败抛异常会导致C++不能正确的释放资源。除非C++程序员精心的设计每个类，并且精心的进行每次catch，这实际上是不可能的；而且常常会导致各种复杂性和不稳定。
2，程序判断malloc/new的返回值，这个相对靠谱一点，但实际上也会把程序变得复杂，而且没法控制类库里面malloc/new失败之后会做什么。而且无法解决操作系统的oom_killer带来的问题。
3，无法处理lazy allocation和memory overcommit。这是最致命的。

正确的解决方案是什么？

1，事先规划内存，像memcached、squid那样，规定自己最多用多少内存。如果要拒绝请求，在malloc之前就拒绝，永远不要碰到oom这种事情。因为oom不仅会给自己带来麻烦，还会通过oom_killer给操作系统和其他进程带去麻烦。
2，信任oom_killer，相信内存不足的时候系统会给你腾出你该有的内存。（内存不足的时候malloc/new是会阻塞的等oom_killer把活儿干完的。所以，如果malloc/new失败了，那就是连oom_killer都找不出可杀的进程了）
3，不要信任oom_killer，是的，这和上面是矛盾的。oom_killer拥有非常高的优先级，常常会引起swap，会造成各种意料之外的副作用。你最好永远都不要遇到它。
4，在linux下要信任glibc的malloc，网上很多文章介绍说malloc碎片什么的，都是炒冷饭。如果你不明白原理和最新的进展，那么就信任malloc。实在内存分配多，就搞个mem pool。
5，做好监控，和自动重启。由于oom_killer等意外的存在，监控和自动重启是必须的。另外，coredump的客观存在也要求监控和自动重启。

wwwsq

补充一下，在上面的事情都做了之后，如果还oom，那就让进程去死吧。异常也好，空指针也好，早死早干净。然后让监控程序把进程自动重启，从头来过。这比勉强运行要可靠得多。

doswin

不用的就赶紧释放。
如果还不行。。给机器加内存吧。

doswin

wwwsq 发表于 2012-05-09 10:14
作为一个C/C++程序员，应该怎么应对OOM，尤其是作为一个linux server开发者？

如果内存用光，还有交换分区，这一读写磁盘，速度变慢。所以，还是自己管理内存为好。

wolf5729

程序预申请内容，自己管理，才能足够放心。

------------------------------------
欢迎光临我的博客：www.danoking.com [DNK的博客]

wwwsq

如果操作系统能为进程配置保留特定数量的内存就好了，这可以提高程序的稳定性（让程序自己去开内存池保证自己的内存使用，是比较困难的）。
这件事情目前是虚拟机做的，虚拟机有点太重型了。

目前的实践都是部署隔离。如果要部署在一起，都要先考虑过资源争用的问题。除了内存，还有max open fd、cpu load、disk space之类的东西要考虑。

程序问题和部署实践是密切相关的。