Questions tagged «oom»

我在server_A上只有一个50 GB的文件，并将其复制到server_B。我跑 server_A$ rsync --partial --progress --inplace --append-verify 50GB_file root@server_B:50GB_file Server_B具有32 GB的RAM和2 GB的交换空间。它大部分是空闲的，应该有很多可用的RAM。它具有足够的磁盘空间。由于远程端已关闭连接，因此传输中止大约为32 GB。 Server_B现在已脱离网络。我们要求数据中心重新启动它。当我查看崩溃之前的内核日志时，我发现它正在使用0字节的交换空间，并且进程列表使用的内存很少（rsync进程被列为使用600 KB的RAM），但是oom_killer是变得疯狂，日志中的最后一件事就是杀死了metalog的内核读取器进程。 这是32位内核3.2.59（因此，任何进程都不能映射超过4 GB的内存）。 几乎就像Linux给缓存提供了比长期运行的守护程序更高的优先级。是什么赋予了？？我该如何阻止它再次发生？ 这是oom_killer的输出： Sep 23 02:04:16 [kernel] [1772321.850644] clamd invoked oom-killer: gfp_mask=0x84d0, order=0, oom_adj=0, oom_score_adj=0 Sep 23 02:04:16 [kernel] [1772321.850649] Pid: 21832, comm: clamd Tainted: G C 3.2.59 #21 Sep 23 02:04:16 [kernel] …

66 rsync  oom  oom-killer 

Linux上的OOM杀手经常对各种应用程序造成破坏，并且似乎并没有在内核开发方面做太多改进。作为设置新服务器的最佳实践，将内存过量使用的默认设置反转为默认值，也就是将其关闭（vm.overcommit_memory=2），除非您知道要为特定用途打开它，否则会更好吗？在您知道要过度使用的情况下，这些用例将是什么？ 另外，由于行为vm.overcommit_memory=2取决于vm.overcommit_ratio和交换空间，因此，调整后两者的大小以使整个设置合理地工作将是一个很好的经验法则吗？

37 linux  memory  kernel  oom 

当物理内存不足但有足够的交换空间时，如何使Linux OOM杀手程序不杀死我的进程？ 我已禁用OOM杀死功能并使用sysctl vm.overcommit_memory = 2来过量使用。 VM具有3 GB的绝对免费的无碎片交换，并且被OOM杀死的进程的最大内存使用量小于200MB。 我知道长期交换对于性能而言将是可怕的，但是我现在需要使用交换来在内存需求更大的valgrind下进行功能测试。 Mar 7 02:43:11 myhost kernel: memcheck-amd64- invoked oom-killer: gfp_mask=0x24002c2, order=0, oom_score_adj=0 Mar 7 02:43:11 myhost kernel: memcheck-amd64- cpuset=/ mems_allowed=0 Mar 7 02:43:11 myhost kernel: CPU: 0 PID: 3841 Comm: memcheck-amd64- Not tainted 4.4.0-x86_64-linode63 #2 Mar 7 02:43:11 myhost kernel: Hardware name: …

28 linux  swap  oom 

今天，我（偶然地）在Linux机器上运行了一些程序，该程序很快占用了大量内存。我的系统死机了，变得反应迟钝，因此我无法杀死罪犯。 将来如何预防？它至少不能保持响应性内核或其他组件正在运行吗？

25 linux  oom 

我有连续的oom＆panic情况无法解决。我不确定系统是否已填满所有RAM（36GB）。为什么这个系统触发了这种oom状态？我怀疑它与32位linux系统中的lowmem区域有关。我该如何分析内核崩溃和oom-killer中的日志？ 最好的祝福， 内核3.10.24 Dec 27 09:19:05 2013 kernel: : [277622.359064] squid invoked oom-killer: gfp_mask=0x42d0, order=3, oom_score_adj=0 Dec 27 09:19:05 2013 kernel: : [277622.359069] squid cpuset=/ mems_allowed=0 Dec 27 09:19:05 2013 kernel: : [277622.359074] CPU: 9 PID: 15533 Comm: squid Not tainted 3.10.24-1.lsg #1 Dec 27 09:19:05 2013 kernel: : [277622.359076] …

15 linux  kernel-panic  oom  oom-killer 

在Google上查看时，找不到任何解释得分proc/<pid>/oom_score计算方式的信息。为什么要使用此分数而不是仅使用已使用的总内存？

12 oom 

尽管我们将近一半的内存用于FS缓存，但我们一直在使用OOM杀手。我们每分钟记录一次内存统计信息（如上图所示），但是似乎有很多可用性。 ... Mem: 15339640k total, 15268304k used, 71336k free, 3152k buffers Swap: 0k total, 0k used, 0k free, 6608384k cached Mem: 15339640k total, 14855280k used, 484360k free, 13748k buffers Swap: 0k total, 0k used, 0k free, 6481852k cached [OOM killer: postgres killed] Mem: 15339640k total, 8212200k used, 7127440k free, 32776k …

12 postgresql  oom 

问题 多次“内存不足”消息后，服务器崩溃了，我试图查明罪魁祸首。如果在用户区中-哪个进程。如果在内核中-哪个内核模块。 细节 我正在尝试找出如何使用崩溃实用工具来调查是什么触发了服务器上的OOM。 作为安装新服务器对的一部分，我开始了14TB DRBD设备的初始化。大约那个时候，在使用DRBD同步器速率配置并上下移动某些绑定网络接口时，其中一台服务器崩溃了。在30秒内，它产生了39条Out of memory: Kill process ####消息。然后它崩溃了： Kernel panic - not syncing: Out of memory and no killable processes... 系统崩溃触发了一个kdump。现在，我有一个不错的vmcore.flat文件，应该可以直接使用它来调查问题，但是我很难找出所有内存的去向。 我知道的唯一资源是Dedoimedo的站点（该站点提供了很好的说明）以及Kernel Crash Book。这些也恰巧是答案中建议的唯一资源，因此我认为这crash是调查的唯一方法。 如果有另一种方法可以对事件进行事后分析，我愿意接受。正是这是crash我知道的唯一实用程序。我现在所拥有的只是vmcore.flat文件，我所需要知道的是哪个组件占用了所有内存。我怀疑内核模块有问题，更具体地说是绑定模块之一（当我关闭接口时触发了它），DRBD模块（在CentOS 6.3上从树构建的版本8.3.15）或其中一个10G以太网模块（mlnx_en从我关闭的接口树中构建，或在bnx2x保持活动状态的接口中树内构建）。我所需要知道的是，是否有办法证实我的怀疑。 到目前为止，我仅使用崩溃实用程序提取了以下信息： 检查使用了多少内存 $ crash /usr/lib/debug/lib/modules/2.6.32-279.5.2.el6.x86_64/vmlinux vmcore.flat .... crash> kmem -i PAGES TOTAL PERCENTAGE TOTAL MEM 16482587 62.9 GB ---- FREE 54610 …

12 centos6  troubleshooting  server-crashes  memory-leak  oom 

尽管我的系统上有足够的可用RAM，但OOM杀手似乎正在杀死东西： （全分辨率） （全分辨率） 27分钟和408个处理之后，系统再次开始响应。大约一个小时后，我重新启动了它，此后不久，内存使用率恢复了正常（对于这台机器）。 经过检查，我的计算机上运行了一些有趣的过程： USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND [...snip...] root 1399 60702042 0.2 482288 1868 ? Sl Feb21 21114574:24 /sbin/rsyslogd -i /var/run/syslogd.pid -c 4 [...snip...] mysql 2022 60730428 5.1 1606028 38760 ? Sl Feb21 21096396:49 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock …

11 linux  centos6  linode  oom 

是否有任何方法可以获取核心转储或能够调试已被oom-killer杀死的进程？ 甚至设置oom-killer尝试使用ABRT终止进程？

10 oom  dump 

EDIT2：此问题在3.8.0-25-通用＃37-Ubuntu SMP下似乎也存在 编辑：我修改了原始标题为“为什么用dd写入文件会触发Linux内存不足管理器”的问题？为了更好地反映出我对以下所述的一般问题感到担忧： 我遇到一个麻烦的情况，当我写一个大小超过内存限制（设置为300MB）的文件时，OOM杀手正在我的LXC容器中强行杀死进程。当我在实际上只有512 MB RAM的Xen虚拟机（EC2 t1.micro）上运行应用程序时，不会发生此问题，因此在尊重容器内存限制的情况下文件缓冲似乎存在一些问题。 作为一个简单的示例，我可以演示dd写入的大文件将如何引起问题。同样，此问题困扰着所有应用程序。我正在寻找解决应用程序缓存过大的一般问题。我了解如何使“ dd”工作。 场景： 我有一个LXC容器，其中memory.limit_in_bytes设置为300 MB。 我尝试将dd添加到约500 MB的文件，如下所示： dd if=/dev/zero of=test2 bs=100k count=5010 大约20％的时间，Linux OOM管理器由该命令触发，并且进程被杀死。不用说，这是非常意想不到的行为。dd旨在模拟容器中运行的程序编写的实际“有用”文件。 详细信息：虽然文件缓存变大（260 MB），但rss和文件映射似乎仍然很低。这是一个在写入过程中memory.stat可能看起来像的示例： cache 278667264 rss 20971520 mapped_file 24576 pgpgin 138147 pgpgout 64993 swap 0 pgfault 55054 pgmajfault 2 inactive_anon 10637312 active_anon 10342400 inactive_file 278339584 active_file 319488 unevictable 0 hierarchical_memory_limit …

10 linux  ubuntu  lxc  oom  cgroup 

我正在调查为什么我们的两个进程被Linux OOM杀手杀死了-尽管这两个时间似乎都有足够的RAM和大量SWAP。 当我将此答案解释为第一个内存请求时，它要求2 ^ 2 = 4页（16KB）的内存（顺序标志），并希望它来自“ Normal”区域。 Jan 27 04:26:14 kernel: [639964.652706] java invoked oom-killer: gfp_mask=0x26000c0, order=2, oom_score_adj=0 如果我正确地解析了输出，则有足够的空间： Node 0 Normal free:178144kB min:55068kB low:68832kB high:82600kB 几分钟后第二次有相同的请求-似乎也有足够的空间。 那么为什么会触发OOM杀手？我将信息解析错误吗？ 系统是带有4.4.0-59 x64内核的14.04 Ubuntu 该vm.overcommit_memory设置设置为“ 0”（启发式），可能不是最佳选择。 实例一： Jan 27 04:26:14 kernel: [639964.652706] java invoked oom-killer: gfp_mask=0x26000c0, order=2, oom_score_adj=0 Jan 27 04:26:14 kernel: …

9 linux  oom 

运行约18小时后，该系统使用了约10GB的内存，导致在执行我们的常规任务时触发OOM杀手： # free -h total used free shared buffers cached Mem: 14G 9.4G 5.3G 400K 27M 59M -/+ buffers/cache: 9.3G 5.4G Swap: 0B 0B 0B # cat /proc/meminfo MemTotal: 15400928 kB MemFree: 5567028 kB Buffers: 28464 kB Cached: 60816 kB SwapCached: 0 kB Active: 321464 kB Inactive: 59156 kB Active(anon): …

9 linux  ubuntu  memory-usage  memory-leak  oom 

我的团队在尝试执行由OutOfMemoryErrors触发的良好堆转储时遇到了困难。由于特定的原因，我们目前正在使用从bash脚本调用的jmap进行转储，而不是使用HeapDumpOnOutOfMemoryError标志。我们正在使用堆大小约为3 GB的64位1.6 JVM。我们的堆转储在90％的时间内失败（猜测）。 我们是否可以采取任何措施来提高获得干净堆转储的可能性，以解决内存问题？我已经读到jmap在Java 1.4中存在主要问题，但是现在应该主要解决这些问题。

9 java  oom  outofmemoryerror  dump