有关OOM killer和磁盘缓存的问题

[rosynirvana]

好像没什么影响OOM的设置...
我是先获取i386版的vm目录文件列表,然后用这个列表分别在两个系统的vm目录执行md5sum
没发现有什么异常的不同
还有一个可能很重要?的不同就是发生kill的是4.x内核
没发生kill的是3.x内核
(困了,具体版本懒得纠结了)
难道连OOM机制都调整了?

一个简单分配内存的试验程序通常只是因为一些简单的signal而终止，而不会触发OoM
OoM发生的时候系统一般都会卡上一段时间，然后log里会有很多关于OoM的信息

[科学之子]

好像没什么影响OOM的设置...
我是先获取i386版的vm目录文件列表,然后用这个列表分别在两个系统的vm目录执行md5sum
没发现有什么异常的不同
还有一个可能很重要?的不同就是发生kill的是4.x内核
没发生kill的是3.x内核
(困了,具体版本懒得纠结了)
难道连OOM机制都调整了?

一个简单分配内存的试验程序通常只是因为一些简单的signal而终止，而不会触发OoM
OoM发生的时候系统一般都会卡上一段时间，然后log里会有很多关于OoM的信息

又试了一遍,简单的程序如果开一个不行,多开几个就会OOM

dmesg看到: a.out invoked oom-killer: gfp_mask=0x24280ca, order=0, oom_score_adj=0
等一大堆信息,就是这种吗?

被kill的时候确实会卡几十秒

[rosynirvana]

看到log里有oom-killer那就是了

[科学之子]

看到log里有oom-killer那就是了

您说此处所说的"log"指的是dmesg?

[rosynirvana]

kernel log
在debian系中被送到syslogd然后存储在/var/log/syslog，用dmesg也能查看一部分

[科学之子]

楼主试试看把内核升级到4.5?

代码： 全选

Linux debian 4.5.0-0.bpo.1-686-pae #1 SMP Debian 4.5.1-1~bpo8+1 (2016-04-20) i686 GNU/Linux

4.5OOM很快发生,不知道是否是Bug,即使我设置了充足的swap,也还是会很快OOM
viewtopic.php?f=122&t=477954

[rosynirvana]

怎么还是想不开
主要工作进程被系统kill了岂不是丢数据？为什么还会希望它发生？

[wtz]

楼主试试看把内核升级到4.5?

代码： 全选

Linux debian 4.5.0-0.bpo.1-686-pae #1 SMP Debian 4.5.1-1~bpo8+1 (2016-04-20) i686 GNU/Linux

4.5OOM很快发生,不知道是否是Bug,即使我设置了充足的swap,也还是会很快OOM
viewtopic.php?f=122&t=477954

试了一下4.1、4.4、4.5，感觉情况差不多。

另外，注意到：如果在tty下运行测试程序，malloc很快就会失败，同时硬盘也不会狂转；而图形界面下，除了测试程序外，还有很多进程处于活动状态（甚至要求分配内存），此时如果磁盘缓存区太小，kswapd0就会高负荷运行（在htop中能看到kswapd0的CPU使用率较高），导致硬盘卡死。

所以，解决问题的直接办法还是限制磁盘缓存的最低大小。强烈要求内核参数中添加这一选项。

[wtz]

怎么还是想不开
主要工作进程被系统kill了岂不是丢数据？为什么还会希望它发生？

这个就是（多数）Windows用户和（多数）Linux用户的观念差别了。惹了麻烦，一个怨机器，一个自认倒霉。

直接kill确实不太合适，但也不能无止尽地允许任何内存分配请求。所以在分配内存的算法上还需要进一步提高。

磁盘缓存还是应当保留一部分供系统关键进程进行应急响应，所以有必要在内核参数中增加一个最小值选项。

[科学之子]

怎么还是想不开
主要工作进程被系统kill了岂不是丢数据？为什么还会希望它发生？

求教为什么我升级为4.5就很快OOM?
LXDE环境,内核限制为224M内存,开启200%的zram,iceweasel开个天气预报网页就OOM
3.16就没有发生这类现象,最多只是系统很卡,但没有死机.

[科学之子]

楼主试试看把内核升级到4.5?

代码： 全选

Linux debian 4.5.0-0.bpo.1-686-pae #1 SMP Debian 4.5.1-1~bpo8+1 (2016-04-20) i686 GNU/Linux

4.5OOM很快发生,不知道是否是Bug,即使我设置了充足的swap,也还是会很快OOM
viewtopic.php?f=122&t=477954

试了一下4.1、4.4、4.5，感觉情况差不多。

另外，注意到：如果在tty下运行测试程序，malloc很快就会失败，同时硬盘也不会狂转；而图形界面下，除了测试程序外，还有很多进程处于活动状态（甚至要求分配内存），此时如果磁盘缓存区太小，kswapd0就会高负荷运行（在htop中能看到kswapd0的CPU使用率较高），导致硬盘卡死。

所以，解决问题的直接办法还是限制磁盘缓存的最低大小。强烈要求内核参数中添加这一选项。

我和您的需求正好相反,觉得系统卡一些没关系,只要别OOM就好

我这里4.5内核如果内存限制为224M,很容易OOM,3.16就不会.
环境是LXDE+200%zram

[rosynirvana]

这个就是（多数）Windows用户和（多数）Linux用户的观念差别了。惹了麻烦，一个怨机器，一个自认倒霉。

直接kill确实不太合适，但也不能无止尽地允许任何内存分配请求。所以在分配内存的算法上还需要进一步提高。

磁盘缓存还是应当保留一部分供系统关键进程进行应急响应，所以有必要在内核参数中增加一个最小值选项。

首先我没看出这为什么是自认倒霉，之前我也没见过哪个windows用户认为，没内存的时候系统应该把自己主要工作进程杀掉，让自己丢数据

然后下面两句话有多少是你猜的？
允许任何内存分配，也就是vm.overcommit_memory = 1，我确实不知道哪个发行版默认用这个，只有用作特殊用途的机器会这么设置
Linux当然会预留一部分内存用于基本维护，另外也会预留一部分内存让用户控件申请内存时能够迅速处理

[rosynirvana]

怎么还是想不开
主要工作进程被系统kill了岂不是丢数据？为什么还会希望它发生？

求教为什么我升级为4.5就很快OOM?
LXDE环境,内核限制为224M内存,开启200%的zram,iceweasel开个天气预报网页就OOM
3.16就没有发生这类现象,最多只是系统很卡,但没有死机.

可能性太多了
例如memmap设置的内存地址冲突了之类的

mem=nn[KMG] [KNL,BOOT] Force usage of a specific amount of memory
Amount of memory to be used when the kernel is not able
to see the whole system memory or for test.
[X86] Work as limiting max address. Use together
with memmap= to avoid physical address space collisions.
Without memmap= PCI devices could be placed at addresses
belonging to unused RAM.

[科学之子]

怎么还是想不开
主要工作进程被系统kill了岂不是丢数据？为什么还会希望它发生？

求教为什么我升级为4.5就很快OOM?
LXDE环境,内核限制为224M内存,开启200%的zram,iceweasel开个天气预报网页就OOM
3.16就没有发生这类现象,最多只是系统很卡,但没有死机.

可能性太多了
例如memmap设置的内存地址冲突了之类的

mem=nn[KMG] [KNL,BOOT] Force usage of a specific amount of memory
Amount of memory to be used when the kernel is not able
to see the whole system memory or for test.
[X86] Work as limiting max address. Use together
with memmap= to avoid physical address space collisions.
Without memmap= PCI devices could be placed at addresses
belonging to unused RAM.

thank~!
把memmap参数去掉,就不会OOM了
不过,为何会冲突呢?3.16就算不去掉memmap参数也正常.

[wtz]

这个就是（多数）Windows用户和（多数）Linux用户的观念差别了。惹了麻烦，一个怨机器，一个自认倒霉。

直接kill确实不太合适，但也不能无止尽地允许任何内存分配请求。所以在分配内存的算法上还需要进一步提高。

磁盘缓存还是应当保留一部分供系统关键进程进行应急响应，所以有必要在内核参数中增加一个最小值选项。

首先我没看出这为什么是自认倒霉，之前我也没见过哪个windows用户认为，没内存的时候系统应该把自己主要工作进程杀掉，让自己丢数据

然后下面两句话有多少是你猜的？
允许任何内存分配，也就是vm.overcommit_memory = 1，我确实不知道哪个发行版默认用这个，只有用作特殊用途的机器会这么设置
Linux当然会预留一部分内存用于基本维护，另外也会预留一部分内存让用户控件申请内存时能够迅速处理

我承认我没有研究过内核的代码，但是这不代表我所说的都是”猜测“，没有根据。
我是站在用户体验的角度，而不是技术的角度来看OOM这个问题。多数Windows用户才不会管系统是如何分配内存的，他们只知道系统应当正确地处理正在运行的程序，不能随意停止响应。至于这背后到底是OOM还是overcommit的算法在发挥作用，他们不关心。但这恰恰是影响用户使用感受的重要方面。

所以说，没有站在用户（这里主要指初学者）的角度考虑问题，这是很多Linux发行版不被广泛认可的主要原因。

另外，类似”Linux不是小白玩的系统“这样的论调，也间接助长了社区在改善Linux用户体验方面的惰性。