• [C++] 应该如何应对OOM?


    作为一个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的客观存在也要求监控和自动重启。

  • 相关阅读:
    黑产上演《三体》剧情:蠕虫病毒入侵手机群发“钓鱼”短信
    安天AVL联合小米MIUI首擒顽固病毒“不死鸟”
    阿里云存储OSS服务端签名客户端直传
    mariadb 安装配置
    NPOI 打印设置
    windows2008 r2 网络负载均衡搭建
    SqlServer数据库技巧
    达梦数据库备份还原
    ASP.NET CORE Docker发布记录
    DataReader转换
  • 原文地址:https://www.cnblogs.com/hehe520/p/6330382.html
Copyright © 2020-2023  润新知