标签: out-of-memory

今天早些时候，建设东西的时候，我决定运行make为

$ make -j

也许是出于与其他软件的习惯，如cabal其中-j默认为一个合理的限度。

大约 20 秒后，我的整个桌面都停止了。我寻找各种活动迹象。没有粉丝旋转。HDD 指示灯呈稳定的绿色，但我没有听到磁盘活动。嗯嗯。沉默了 10 分钟后，我终于看到了我很久以前第一次按键的反应，并且我也开始听到非常熟悉的磁盘抖动声音。20 分钟后，我慢慢地尝试涉水进入这台没有响应的机器上的终端，我屈服并使用了 REISUB。

起初，我认为一个不相关的桌面应用程序一定是罪魁祸首，因为我早就对交互式 bash 会话设置了内存限制，以防止我将自己置于这种情况！但/var/log/syslog讲述了一个不同的故事；在OOM杀手留下一些ps垃圾场被怀疑的包装与c++和cc1plus流程！

以下是其中一个转储的频率分析：

Command          Number of appearances
'sh'                    322
'c++'                   321
'cc1plus'               321
'chrome'                 27
'make'                   27
'bash'                    3
all else combined       120

所以我检查了 GNU make 的手册页：（强调）

-j [jobs], --jobs[=jobs] 指定要同时运行的作业（命令）的数量。如果有多个 -j 选项，则最后一个有效。 如果 -j 选项不带参数给出，make 将不会限制可以同时运行的作业数量。

我不愿意看到我是否能重现该问题（医生，我这样做时，它会伤害这个 …

解释如下：Linux 是否会在不询问我内存是否不足的情况下开始杀死我的进程？可以通过以下方式配置OOM-Killer overcommit_memory：

• 2 = 没有过量使用。如果要求太多，分配就会失败。
• 0, 1 = 过量使用（启发式或始终）。当实际访问太多内存时，根据一些启发式杀死一些进程。

现在，我可能完全误解了这一点，但是为什么没有一个选项（或者为什么它不是默认值）来终止实际尝试访问它分配的太多内存的进程？

我有一个令人困惑的问题。我有一个使用sg执行自定义 CDB的库。有几个系统通常会在sg 中出现内存分配问题。通常，sg驱动程序有大约 4mb 的硬限制，但我们在这些具有 ~2.3mb 请求的少数系统上看到它。也就是说，CDB 正准备分配 2.3mb 的传输。这里不应该有任何问题：2.3 < 4.0。

现在，机器的配置文件。它是一个 64 位 CPU，但运行 CentOS 6.0 32 位（我没有构建它们，也与这个决定没有任何关系）。这个 CentOS 发行版的内核版本是 2.6.32。他们有 16GB 的内存。

以下是系统上的内存使用情况（不过，因为此错误发生在自动化测试期间，我尚未验证这是否反映了从sg返回此 errno 时的状态）。

top - 00:54:46 up 5 days, 22:05,  1 user,  load average: 0.00, 0.01, 0.21
Tasks: 297 total,   1 running, 296 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  15888480k total,  9460408k used,  6428072k free,   258280k buffers
Swap:  4194296k …

每当我重新启动我的笔记本电脑时，一切都运行得惊人，而且我的内存使用率最高为 40%（超过 8GB）。然而，随着时间的推移（使用约 1 天），内存使用率上升到 90% 以上，并且系统开始交换。

现在，free -mh返回这个：

              total        used        free      shared  buff/cache   available
Mem:           7,7G        1,3G        141M        223M        6,3G        246M
Swap:          7,5G        530M        6,9G

我假设如果进程需要，可以自由地重新分配 buff/缓存内存，但它似乎大多不可用。

cat /proc/meminfo：

MemTotal:        8055268 kB
MemFree:          145184 kB
MemAvailable:     247984 kB
Buffers:           49092 kB
Cached:           423724 kB
SwapCached:        38652 kB
Active:           881184 kB
Inactive:         791552 kB
Active(anon):     708420 kB
Inactive(anon):   725564 kB
Active(file):     172764 kB
Inactive(file):    65988 kB
Unevictable:         252 kB
Mlocked:             252 kB
SwapTotal:       7812092 kB
SwapFree:        7267624 …

在我们的一个 MySQL master 上，OOM Killer 被调用并杀死了 MySQL 服务器，导致大停电。以下是内核日志：

[2006013.230723] mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0
[2006013.230733] Pid: 1319, comm: mysqld Tainted: P           2.6.32-5-amd64 #1
[2006013.230735] Call Trace:
[2006013.230744]  [<ffffffff810b6708>] ? oom_kill_process+0x7f/0x23f
[2006013.230750]  [<ffffffff8106bde2>] ? timekeeping_get_ns+0xe/0x2e
[2006013.230754]  [<ffffffff810b6c2c>] ? __out_of_memory+0x12a/0x141
[2006013.230757]  [<ffffffff810b6d83>] ? out_of_memory+0x140/0x172
[2006013.230762]  [<ffffffff810baae8>] ? __alloc_pages_nodemask+0x4ec/0x5fc
[2006013.230768]  [<ffffffff812fca02>] ? io_schedule+0x93/0xb7
[2006013.230773]  [<ffffffff810bc051>] ? __do_page_cache_readahead+0x9b/0x1b4
[2006013.230778]  [<ffffffff810652f8>] ? wake_bit_function+0x0/0x23
[2006013.230782]  [<ffffffff810bc186>] ? ra_submit+0x1c/0x20
[2006013.230785]  [<ffffffff810b4e53>] ? filemap_fault+0x17d/0x2f6
[2006013.230790]  [<ffffffff810cae1e>] ? __do_fault+0x54/0x3c3
[2006013.230794]  [<ffffffff812fce29>] ? __wait_on_bit_lock+0x76/0x84
[2006013.230798]  [<ffffffff810cd172>] ? handle_mm_fault+0x3b8/0x80f
[2006013.230803] …

评估 /proc/meminfo 后，我看到以下信息：

$cat /proc/meminfo
MemTotal:       197852592 kB
MemFree:        64755992 kB
MemAvailable:   65655112 kB
Buffers:            4388 kB
Cached:           759952 kB
SwapCached:            0 kB
Active:           649472 kB
Inactive:         308340 kB
Active(anon):     193840 kB
Inactive(anon):    25316 kB
Active(file):     455632 kB
Inactive(file):   283024 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:       4095932 kB
SwapFree:        4095932 kB
Dirty:                 8 kB
Writeback:             0 kB
AnonPages:        193560 kB
Mapped:            86208 kB
Shmem:             25684 kB
Slab:           49141432 kB
SReclaimable:     667284 kB
SUnreclaim:     48474148 kB
KernelStack:       25600 kB …

我发现当遇到内存不足的 OOM 情况时，我的 linux box UI 完全冻结了很长时间。

我已经设置了magic-sysrq-key然后使用 echo 1 | tee /proc/sys/kernel/sysrq并遇到OOM-> UI无响应情况能够按下Alt-Sysrq-f它，如dmesg日志所示导致OOM终止/终止进程并由此解决OOM情况。

我的问题是现在。为什么 linux 变得像 GUI 冻结一样无响应，但似乎没有触发相同的 OOM-Killer，我确实通过Alt-Sysrq-f组合键手动触发了它？

考虑到在 OOM“冻结”情况下，系统反应迟钝，甚至不允许及时（< 10 秒）响应击中Ctrl-Alt-F3（切换到 tty3），我不得不假设内核必须意识到它的反应迟钝，但仍然本身没有调用Alt-Sysrq-fOOM-Killer ，为什么？

这些是一些可能对所描述的行为产生影响的设置。

$> mount | grep memory
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
$> cat /sys/fs/cgroup/memory/memory.oom_control 
oom_kill_disable 0
under_oom 0
oom_kill 0

虽然据我所知，内存 cgroup 既没有激活也没有禁用 OOM（显然必须有充分的理由让 OOM_kill 激活和禁用，或者我可能无法正确解释输出，也under_oom 0有些不清楚，仍然)

我有一个 250 MB 的文本文件，全部在一行中。

在这个文件中，我想a用b字符替换字符：

sed -e "s/a/b/g" < one-line-250-mb.txt

它失败了：

sed: couldn't re-allocate memory

在我看来，这种任务可以在不分配太多内存的情况下内联执行。
是否有更好的工具，或者更好的使用方法sed？

GNU sed 版本 4.2.1
Ubuntu 12.04.2 LTS
1 GB RAM

如果我通过设置vm.overcommit_memory为禁用内存过量使用2，默认情况下系统将允许分配内存最多为交换维度 + 50% 的物理内存，如解释here。

我可以通过修改vm.overcommit_ratio参数来改变比例。假设我将其设置为 80%，因此可能会使用 80% 的物理内存。

我的问题是：

• 系统将如何处理剩余的 20%？
• 为什么首先需要这个参数？
• 为什么我不应该总是将其设置为 100%？

所以，我认为这将是一个非常简单的定位：一个服务/内核模块，当内核注意到用户空间内存不足时，会触发一些操作（例如，将进程列表转储到文件中，ping 某个网络端点，等等) 在具有自己专用内存的进程中（因此它不会失败 fork() 或遭受任何其他常见的 OOM 问题）。

我发现了OOM 杀手，我认为它很有用，但它并没有真正做我需要做的事情。

理想情况下，如果我的内存不足，我想知道原因。我想我可以编写自己的程序，在启动时运行并使用固定数量的内存，然后仅在内核通知内存不足时才执行操作，但这带来了它自己的问题......

甚至有一个系统调用被告知类似的事情吗？一种对内核说“嘿，当我们只剩下 128 MB 内存时叫醒我”的方法？

我在网上和这里搜索，但没有找到任何符合该描述的内容。似乎大多数人在时间延迟上使用轮询，但明显的问题是它使您不太可能知道是哪个进程导致了问题。