Golang 的 GC 在内存耗尽时运行

在 Go 应用程序遭遇内存耗尽（OOM）时，内核会作为最后手段启动 OOM Killer，牺牲该进程以避免系统崩溃。在这种情况下，应用程序无法控制 OOM Killer 的行为，也无法提前收到警告。如果应用程序在处理大型文件时遇到 OOM，解决方案是提高容器的内存限制或优化程序的内存消耗，限制并发性并避免为每一行创建一个协程。

golang遇到OOM时是否会运行GC并重试分配？

我们面临一个问题，即 kubernetes pod（运行 go 代码）在处理大文件时被 OOM Killed。

go代码处理许多文件，逐行读取它们，并为其解析的每一行（通过在循环中创建解析的结构 - 局部变量来分配一些内存），如果匹配某些条件，则将其插入数据库。 这是为多个客户端同时运行的。 这对于许多拥有小文件的客户端来说效果很好。但是当它遇到客户端的大文件时，就会出现 OOM。

我们的系统运行了很长时间，没有发现任何内存泄漏。即使 pprof 分析也表明没有内存泄漏。

解决方案

OOM杀手是内核面临内存压力时的最后手段。 “要么我现在牺牲一个进程，要么整个系统可能变得无法使用。”

因为这是最后的手段（例如，内核会在调用 OOM 杀手之前很久就选择减少文件系统缓存的可用内存量），因此被选择牺牲的进程在这方面没有发言权没有预警¹。

在您的情况下，您可能没有耗尽物理内存，而是达到了容器的用户定义内存限制。但内核也使用相同的设施来强制执行此限制。

您必须提高内存限制以应对最坏情况的工作负载，或提高程序的内存消耗以使其保持在限制范围内。

鉴于小文件可以正常工作，因此您没有适当限制并发性是理所当然的。如果您一次为每一行生成一个 goroutine，则就内存使用而言，与读取整个文件没有根本区别。 Concurrency can be easily limited with a semaphore

1. 您可以将 SIGKILL 更改为 SIGTERM，但这对您没有帮助。如果您将 SIGTERM 的含义从“退出”更改为“向操作系统释放一些内存但继续运行”，您的运维团队会讨厌您。无论如何，Go 也没有办法做到这一点。

今天带大家了解了的相关知识，希望对你有所帮助；关于Golang的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~