文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

golang进程在docker中OOM后hang住问题解析

2024-04-02 19:55

关注

正文

golang版本:1.16

背景:golang进程在docker中运行,因为使用内存较多,经常在内存未达到docker上限时,就被oom-kill,为了避免程序频繁被杀,在docker启动时禁用了oom-kill,但是出现了新的问题。

现象:docker内存用满后,golang进程hang住,无任何响应(没有额外内存系统无法分配新的fd,无法服务),即使在程序内置了内存达到上限就重启,也不会生效,只能kill

因为pprof查看进程内存有很多是能在gc时释放的,起初怀疑是golang进程问题

在hang住之前,先登录到docker上,写一个golang测试程序,只申请一小段内存后sleep,启动时加GODEBUG=GCTRACE=1打印gc信息,发现mark 阶段stw耗时达到31s(31823+15+0.11 ms对应STW Mark Prepare,Concurrent Marking,STW Mark Termination)

怀疑是不是申请内存失败后,没有触发oom退出。在golang标准库中查看oom相关的逻辑

mgcwork.go:374

if s == nil {
   systemstack(func() {
      s = mheap_.allocManual(workbufAlloc/pageSize, spanAllocWorkBuf)
   })
   if s == nil {
      throw("out of memory")
   }
   // Record the new span in the busy list.
   lock(&work.wbufSpans.lock)
   work.wbufSpans.busy.insert(s)
   unlock(&work.wbufSpans.lock)
}

mheap分配内存使用了mmap,继续怀疑是mmap返回的错误码在docker中不是非0

func sysMap(v unsafe.Pointer, n uintptr, sysStat *sysMemStat) {
   sysStat.add(int64(n))
   p, err := mmap(v, n, _PROT_READ| _PROT_WRITE, _MAP_ANON| _MAP_FIXED| _MAP_PRIVATE, -1, 0)
   if err == _ENOMEM {
      throw("runtime: out of memory")
   }
   if p != v || err != 0 {
      throw("runtime: cannot map pages in arena address space")
   }
}

为了对比验证,用c写一段调用mmap的代码,在同一个docker中同时跑看下

#include <sys/mman.h>
#include <unistd.h>
#include <errno.h>
#include <stdio.h>
#define BUF_SIZE 393216
void main() {
    char *addr;
    int i;
    for(i=0;i<1000000;i++) {
        addr = (char *)mmap(NULL, BUF_SIZE, PROT_READ | PROT_WRITE,
                MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
        if (addr != MAP_FAILED) {
            addr[0] = 'a';
            addr[BUF_SIZE-1] = 'b';
            printf("i:%d, sz: %d, addr[0]: %c, addr[-1]: %c\n", i, BUF_SIZE, addr[0], addr[BUF_SIZE-1]);
            munmap(addr, BUF_SIZE);
        } else {
            printf("error no: %d\n", errno);
        }
        usleep(1000000);
    }
}

mmap没有失败,而且同样会hang住,说明不是golang机制的问题,应该是阻塞在了系统调用上。查看调用堆栈,发现是hang在了cgroup中

[<ffffffff81224d65>] mem_cgroup_oom_synchronize+0x275/0x340
[<ffffffff811a068f>] pagefault_out_of_memory+0x2f/0x74
[<ffffffff81066bed>] __do_page_fault+0x4bd/0x4f0
[<ffffffff81801605>] async_page_fault+0x45/0x50
[<ffffffffffffffff>] 0xffffffffffffffff

查看go程序,也有相同的调用堆栈

[<ffffffff81103681>] futex_wait_queue_me+0xc1/0x120
[<ffffffff81104086>] futex_wait+0xf6/0x250
[<ffffffff8110647b>] do_futex+0x2fb/0xb20
[<ffffffff81106d1a>] SyS_futex+0x7a/0x170
[<ffffffff81003948>] do_syscall_64+0x68/0x100
[<ffffffff81800081>] entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[<ffffffffffffffff>] 0xffffffffffffffff
[<ffffffff810f3ffe>] hrtimer_nanosleep+0xce/0x1e0
[<ffffffff810f419b>] SyS_nanosleep+0x8b/0xa0
[<ffffffff81003948>] do_syscall_64+0x68/0x100
[<ffffffff81800081>] entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[<ffffffffffffffff>] 0xffffffffffffffff
[<ffffffff81224c5a>] mem_cgroup_oom_synchronize+0x16a/0x340
[<ffffffff811a068f>] pagefault_out_of_memory+0x2f/0x74
[<ffffffff81066bed>] __do_page_fault+0x4bd/0x4f0
[<ffffffff81801605>] async_page_fault+0x45/0x50
[<ffffffffffffffff>] 0xffffffffffffffff
[<ffffffff81224c5a>] mem_cgroup_oom_synchronize+0x16a/0x340
[<ffffffff811a068f>] pagefault_out_of_memory+0x2f/0x74
[<ffffffff81066bed>] __do_page_fault+0x4bd/0x4f0
[<ffffffff81801605>] async_page_fault+0x45/0x50
[<ffffffffffffffff>] 0xffffffffffffffff
[<ffffffff81224c5a>] mem_cgroup_oom_synchronize+0x16a/0x340
[<ffffffff811a068f>] pagefault_out_of_memory+0x2f/0x74
[<ffffffff81066bed>] __do_page_fault+0x4bd/0x4f0
[<ffffffff81801605>] async_page_fault+0x45/0x50
[<ffffffffffffffff>] 0xffffffffffffffff

看了下cgroup内存控制的代码,策略是没有可用内存并且未配置oom kill的程序,会锁在一个等待队列里,当有可用内存时再从队首唤醒。这个逻辑没办法通过配置或者其他方式绕过去。

elixir.bootlin.com/linux/v4.14…

 
bool mem_cgroup_oom_synchronize(bool handle)
{
        struct mem_cgroup *memcg = current->memcg_in_oom;
        struct oom_wait_info owait;
        bool locked;
        
        if (!memcg)
                return false;
        if (!handle)
                goto cleanup;
        owait.memcg = memcg;
        owait.wait.flags = 0;
        owait.wait.func = memcg_oom_wake_function;
        owait.wait.private = current;
        INIT_LIST_HEAD(&owait.wait.entry);
        prepare_to_wait(&memcg_oom_waitq, &owait.wait, TASK_KILLABLE);
        mem_cgroup_mark_under_oom(memcg);
        locked = mem_cgroup_oom_trylock(memcg);
        if (locked)
                mem_cgroup_oom_notify(memcg);
        if (locked && !memcg->oom_kill_disable) {
                mem_cgroup_unmark_under_oom(memcg);
                finish_wait(&memcg_oom_waitq, &owait.wait);
                mem_cgroup_out_of_memory(memcg, current->memcg_oom_gfp_mask,
                                         current->memcg_oom_order);
        } else {
                schedule();
                mem_cgroup_unmark_under_oom(memcg);
                finish_wait(&memcg_oom_waitq, &owait.wait);
        }
        if (locked) {
                mem_cgroup_oom_unlock(memcg);
                
                memcg_oom_recover(memcg);
        }
cleanup:
        current->memcg_in_oom = NULL;
        css_put(&memcg->css);
        return true;
}

结论:

docker内存耗光后,golang在gc的mark阶段,需要申请新的内存记录被标记的对象时,需要调用mmap,因为没有可用内存,就会被hang在cgroup中,gc无法完成也就无法释放内存,就会导致golang程序一直在stw阶段,无法对外服务,即使压力下降也无法恢复。最好还是不要关闭docker的oom-kill

以上就是golang进程在docker中OOM后hang住问题解析的详细内容,更多关于golang进程docker OOM hang的资料请关注编程网其它相关文章!

阅读原文内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯