中文 
raphaelzhang
deepin
2017-06-29 19:59 deepin 本帖最后由 raphaelzhang 于 2017-6-29 12:00 编辑
不过我觉得earlyoom作为一个可选项倒是可以装的，但是不要缺省装，不然用户估计又要抱怨了
不过我觉得earlyoom作为一个可选项倒是可以装的，但是不要缺省装，不然用户估计又要抱怨了
Reply Like 0 View the author
#21
duanyao
deepin
2017-06-29 20:02 deepin https://bbs.deepin.org/post/141744
刚才讨论了 这个方案可能谁kill其他的应用 导致数据丢失，已经有大神在解决了 ...
为了减少数据丢失的问题，可以暂时借鉴 Windows 的内存不足提示。比如在可用内存 12%-15%触发提示框，而 earlyoom 在 10% 触发，作为最后的安全网。
长期来看，还是应该借鉴 android 的 low memory killer，让用户能“无忧操作”。
Reply Like 0 View the author
duanyao deepin
2017-06-29 20:09 deepin https://bbs.deepin.org/post/141744
tty -> top -> kill还好吧，我自己遇到系统延迟时都可以解决，有时候确实有点慢，但几分钟还没有遇到过。 ...
不知道你的电脑配置如何，这更容易发生在机械硬盘，并运行内存和IO都密集的应用时（例如android-studio、虚拟机）。这个问题说常见吧也不是非常常见，也有很多用户从来没遇到过。
Reply Like 0 View the author
DebuggerX deepin
2017-06-29 20:10 deepin 公司开发机原本8g内存，只开as开发安卓+几十个chrome页面也没问题；
后来连着把后台代码也写了，同时开as和idea，chrome再开几个页面就会卡死；
于是申请加内存，加到了12g，终于又开心地玩耍了一阵；
然而好景不长，后面又开始做其他东西，必须同时开着虚拟机和ide，又开始时不时卡死了……
像这种情况下，确实是只有堆内存才能解决了，软件是无能为力的，，以后真的是得16g起步了。。
后来连着把后台代码也写了，同时开as和idea，chrome再开几个页面就会卡死；
于是申请加内存，加到了12g，终于又开心地玩耍了一阵；
然而好景不长，后面又开始做其他东西，必须同时开着虚拟机和ide，又开始时不时卡死了……
像这种情况下，确实是只有堆内存才能解决了，软件是无能为力的，，以后真的是得16g起步了。。
Reply Like 0 View the author
rdlg
deepin
2017-06-29 20:10 deepin 可能因为Linux长期是作为服务器存在的 感觉这个问题一直没被重视
我之前也调查过这个问题 但是没来得及验证各种猜想
1. 如果确定是持续页面交换导致的 那么减小甚至关闭swap分区是否会有帮助
2. cgroup提供的rss限制是否能够有效遏制这个问题
3. 磁盘读写优先级能否保证某些程序优先相应
4. 是否有类似非换页内存的概念，保证系统关键进程不被换出
从之前使用Windows的经验来看，系统很少因为内存不够出现系统卡死的状况，可能和Windows的图形组件在内核中有关，也可能是因为关键组件存在保护机制。
但是如果是磁盘IO量大，Windows也会卡的不能动，这种情况在Win10之后似乎有所改进，我曾经试过在这种情况下，其他应用都卡的不能动，但是系统的任务管理器在调出来后能够流畅运行。
我之前也调查过这个问题 但是没来得及验证各种猜想
1. 如果确定是持续页面交换导致的 那么减小甚至关闭swap分区是否会有帮助
2. cgroup提供的rss限制是否能够有效遏制这个问题
3. 磁盘读写优先级能否保证某些程序优先相应
4. 是否有类似非换页内存的概念，保证系统关键进程不被换出
从之前使用Windows的经验来看，系统很少因为内存不够出现系统卡死的状况，可能和Windows的图形组件在内核中有关，也可能是因为关键组件存在保护机制。
但是如果是磁盘IO量大，Windows也会卡的不能动，这种情况在Win10之后似乎有所改进，我曾经试过在这种情况下，其他应用都卡的不能动，但是系统的任务管理器在调出来后能够流畅运行。
Reply Like 0 View the author
duanyao deepin
2017-06-29 20:11 deepin https://bbs.deepin.org/post/141744
不过我觉得earlyoom作为一个可选项倒是可以装的，但是不要缺省装，不然用户估计又要抱怨了 ...
我觉得可以，先放到源里，让遇到过这个问题的用户试试。
Reply Like 0 View the author
duanyao deepin
2017-06-29 20:28 deepin 本帖最后由 duanyao 于 2017-6-29 12:38 编辑
你可以看看一楼的附件，不过有点太乱，我简单回答一下：
几乎没有。交换至少有两种，一种是 swap 分区/文件上的交换，一种是 pagecache 的淘汰/填充，后一种的确被很多 linuxer 忽略了。关闭swap分区并不能避免pagecache交换导致的卡死。不过考虑到现在内存和机械硬盘的速度差距是如此之大，关闭 swap 应该有利于保持系统的响应速度（我没有具体的数据），我现在就是关闭的。SSD 就速度来说适合做 swap，但考虑到寿命嘛，就见仁见智了。
有这样的建议，原理上可行，但桌面上还没有开箱即用的方案。
linux 的磁盘调度器长期没啥大改进了，一直推荐cfq，但它显然不能解决机械硬盘上的卡死问题。最近新的 bfq 进了 4.12 内核，有望改善机械硬盘的调度，但还需要一段时间才能被各发行版采用。我们到时候再看。
有的，mlock 系列系统调用。 earlyoom 就用了，保证自己不被换出。
windows 不支持 overcommit，linux 则支持。这样 windows 分配内存比较保守，相对不容易出现此问题（但也会出问题，我也遇到过，任务管理器也出不来，只好重启）。但 linux 不适合关闭 overcommit（尽管是可以的），因为大量的 linux 程序是按照可以 overcommit 的假设编写的，关闭 overcommit 的结果是你必须浪费很大一部分物理内存。
https://bbs.deepin.org/post/141744
可能因为Linux长期是作为服务器存在的 感觉这个问题一直没被重视
我之前也调查过这个问题 但是没来得及验证 ...
你可以看看一楼的附件，不过有点太乱，我简单回答一下：
1. 如果确定是持续页面交换导致的 那么减小甚至关闭swap分区是否会有帮助
几乎没有。交换至少有两种，一种是 swap 分区/文件上的交换，一种是 pagecache 的淘汰/填充，后一种的确被很多 linuxer 忽略了。关闭swap分区并不能避免pagecache交换导致的卡死。不过考虑到现在内存和机械硬盘的速度差距是如此之大，关闭 swap 应该有利于保持系统的响应速度（我没有具体的数据），我现在就是关闭的。SSD 就速度来说适合做 swap，但考虑到寿命嘛，就见仁见智了。
2. cgroup提供的rss限制是否能够有效遏制这个问题
有这样的建议，原理上可行，但桌面上还没有开箱即用的方案。
3. 磁盘读写优先级能否保证某些程序优先相应
linux 的磁盘调度器长期没啥大改进了，一直推荐cfq，但它显然不能解决机械硬盘上的卡死问题。最近新的 bfq 进了 4.12 内核，有望改善机械硬盘的调度，但还需要一段时间才能被各发行版采用。我们到时候再看。
4. 是否有类似非换页内存的概念，保证系统关键进程不被换出
有的，mlock 系列系统调用。 earlyoom 就用了，保证自己不被换出。
从之前使用Windows的经验来看，系统很少因为内存不够出现系统卡死的状况
windows 不支持 overcommit，linux 则支持。这样 windows 分配内存比较保守，相对不容易出现此问题（但也会出问题，我也遇到过，任务管理器也出不来，只好重启）。但 linux 不适合关闭 overcommit（尽管是可以的），因为大量的 linux 程序是按照可以 overcommit 的假设编写的，关闭 overcommit 的结果是你必须浪费很大一部分物理内存。
Reply Like 0 View the author
duanyao deepin
2017-06-29 20:46 deepin https://bbs.deepin.org/post/141744
公司开发机原本8g内存，只开as开发安卓+几十个chrome页面也没问题；
后来连着把后台代码也写了，同时开as和 ...
如果是必须同时运行那就没办法了，不过像浏览器的话我可以接受它被杀掉，反正重新打开时会自动恢复tab。
移动浏览器遇到内存不足时会自动卸载后台tab的，切换过去时又重新加载，桌面浏览器如果借鉴一下就好了。
Reply Like 0 View the author
wtz deepin
2017-06-29 21:31 deepin https://bbs.deepin.org/post/141744
这个帖子很老了，讨论的问题和解决方案并不超出我的认知范围。我关注这个问题也有好几年了，查阅了很多资 ...
明白。
其实这里我想说明的是，在处理内存不足的问题上，开发者和普通用户之间对“内存”的理解差异是造成OOM Killer不能“如期”工作的原因。
开发者眼中：“内存不足”是指进程请求分配更多内存时，（逻辑上）没有更多可供分配的内存；
普通用户眼中：“内存不足”是指（物理）内存用量超过一定限额，导致界面交互出现迟缓。
而在这当中，怎样界定“可供分配的内存”、“内存用量”和“界面交互进程与系统核心进程”，又因操作系统所处场景的不同而不同。
因此，个人认为，对于一个大众化发行版的桌面版本而言，有必要认真考虑以上问题，并根据用户反馈主动调整系统资源的管理策略。
Reply Like 0 View the author
liulangdedao deepin
2017-06-29 21:34 deepin 个人应用的问题了吧，我曾经2g的内存，需要上网的时候，只单开 一个浏览器，标签页保持在三四个，照样愉快的上网，后来加了 一个4g的内存，变成了6g内存，系统顿时流畅了许多，可是没有多久，系统竟然卡死了，后来琢磨了一下，哪一次，我的谷歌开了将近二十个标签页，开着QQ,听着网易云音乐，开着虚拟机……系统不卡死才怪，系统运行的软件，保持一个合理的数目才是王道，否则就算加到32g，你 硬要开一堆程序，照样的卡死！
Reply Like 0 View the author
duanyao deepin
2017-06-29 21:46 deepin https://bbs.deepin.org/post/141744
明白。
其实这里我想说明的是，在处理内存不足的问题上，开发者和普通用户之间对“内存”的理解差异是造 ...
对的。但更准确地说，是操作系统内核没有足够的知识去有效管理用户态程序的内存，很多事情还是要移到用户态来做，甚至移到桌面环境上来做。比如，通知应用保存状态，因为即将杀死应用；让窗口不在前台的应用优先被杀死，等等。
Reply Like 0 View the author
duanyao deepin
2017-06-29 21:49 deepin https://bbs.deepin.org/post/141744
个人应用的问题了吧，我曾经2g的内存，需要上网的时候，只单开 一个浏览器，标签页保持在三四个，照样愉快 ...
希望你能有耐心爬一下楼，如果没有，对比一下别的操作系统，有比较才有鉴别。Android 和 iOS 绝不会因为“ 硬要开一堆程序”而卡死，Windows 也比较少。
Reply Like 0 View the author
134******40 deepin
2017-06-30 01:41 deepin 我决定装个试试，已经死过两三次了，打开虚拟机和几个开发工具就卡死，已经8g内存了
Reply Like 0 View the author
Comments
duanyao
2017-07-01 05:32可以用 46 楼的程序验证一下效果
liulangdedao deepin
2017-06-30 06:03 deepin https://bbs.deepin.org/post/141744
希望你能有耐心爬一下楼，如果没有，对比一下别的操作系统，有比较才有鉴别。Android 和 iOS 绝不会因为 ...
ios没有用过不知道，但是我的安卓手机，确实是开多了软件就要卡死，用的机子比较老，红米1.如今使用的时候，很少打开超过三个程序。至于windows,开多了他会有个提示框，提示你关闭一些程序，
Reply Like 0 View the author
duanyao deepin
2017-06-30 07:22 deepin https://bbs.deepin.org/post/141744
ios没有用过不知道，但是我的安卓手机，确实是开多了软件就要卡死，用的机子比较老，红米1.如今使用的时 ...
我想你的手机不会比我的差：充话费送的 TCL P331M，只有512M内存。即使这样，用了2年也从未出现卡死，而且我也几乎不用任务管理器杀掉应用。当然经常出现的情况是后台应用突然就被系统杀掉了，比如前台用着微信，后台的音乐播放器忽然就没声了。我的另一台中兴U956手机出现过卡死，但与内存不足无关，只在硬解码播放某些视频时出现，可能是底层故障。我想你需要更多分析才能确定卡死的真正原因，如果确实是开多了软件就要卡死，那么我想小米的系统存在严重缺陷。
Windows 的情况我前面也说了，比 Linux 不容易卡死，但也不能完全避免。
Reply Like 0 View the author
q1377195627
deepin
2017-06-30 08:14 deepin https://bbs.deepin.org/post/141744
我觉得还是加钱升内存才是解决之道。自从加了2G内存，6G情况下就没卡过。
呵呵，我8g日常爆炸
Reply Like 0 View the author
justforlxz
2017-06-30 16:51 deepin developers team
https://bbs.deepin.org/post/141744
呵呵，我8g日常爆炸
可能是因为我用的ssd吧，而且6G从来没用到超过4G上。
Reply Like 0 View the author
wangyong
deepin
2017-06-30 17:07 deepin duanyao 发表于 2017-6-29 10:05
不知道你们的解决思路是什么，能否透露一二？
我觉得在现阶段，linux 桌面在内存耗尽的时候丢失数据是无 ...
andriod的解决方案是所有应用都要遵守他的sdk，系统可以随时杀死进程，所以应用会主动保存数据，把保存数据的问题踢给应用开发厂商。桌面linux应用没有统一标准，当然有一天都用深度adk就可以办到了，哈哈哈哈
Reply Like 0 View the author
duanyao deepin
2017-06-30 18:04 deepin https://bbs.deepin.org/post/141744
andriod的解决方案是所有应用都要遵守他的sdk，系统可以随时杀死进程，所以应用会主动保存数据，把保存数 ...
深度自己无疑可以先做起来，这会成为一项杀手级特性的。然后推动它成为 freedesktop.org 的标准，那么其它的 linux 桌面应用也可以加入进来。内存不足通知从原理上说不需要依赖特定 sdk，用 domain socket、dbus 或许都是可行的；自动保存数据就由应用自己实现了，用什么技术都行，不限制。
Reply Like 0 View the author
q1377195627 deepin
2017-06-30 20:11 deepin https://bbs.deepin.org/post/141744
可能是因为我用的ssd吧，而且6G从来没用到超过4G上。
我也是ssd好不，而且内存关ssd啥事，该炸还是炸 ，clion日常1-2g，chrome日常好几g
Reply Like 0 View the author
Please sign in first
My beautiful Deepin-colored stock chart theme 
网站： https://github.com/rfjakob/earlyoom
文档的解说已经很详细了，不过因为是英文，我简单介绍一下：
Linux 内核中的 oom-killer 严重不靠谱，往往触发得太迟。在它工作之前，系统往往已经没救了，或者用户已经被卡得失去耐心，按了重启键。
earlyoom 是个用户态服务，顾名思义它会较早的触发（默认条件是可用物理内存和交换分区都不足10%），杀掉内存消耗最多的进程，避免系统卡死。
我试了一下还是挺有效的，用 android-studio 编译一个大工程时，它先后杀掉了 chrome、 firefox、vs code，编译得以顺利完成。
建议 deepin 预装这个软件，我相信它能避免相当数量的卡死问题。
注：2017.9 deepin 已经收录了此软件，但没有预装，大家可以用 sudo apt install earlyoom 安装试用。安装后不必做什么，下次重启系统后自动生效。
注2：2019.7 deepin 15.9.2 - 15.11 稳定版仓库里没有此软件（预计v 20恢复），你可以装 debian 仓库里的： http://ftp.cn.debian.org/debian/pool/main/e/earlyoom/earlyoom_1.2-1_amd64.deb
补充：想了一下，还是把我这些年调查内存不足导致卡死的问题是做的笔记发上来。很凌乱，没什么条理，不过里面的很多链接应该是有参考价值的。
发上来的主要目的是说明：我并非是偶尔看到一个软件就兴冲冲的推荐了，这后面是有大量铺垫的。linux_memory_swap_thrashing.zip
linux_memory_swap_thrashing.zip
再补充：还没有经历过内存不足卡死，或者喜欢作死的小伙伴，可以试试这个小程序：
http://launchpadlibrarian.net/23372552/memory_overcommit.cc
来源是 ubuntu 的一个 bug 报告 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/159356
下载后用 c++ 编译，运行。你需要输入每次分配的内存大小，单位 M，直接回车表示与上次相同。
如果剩余物理内存很多可以500M每步，剩余500M左右时改为100M每步，剩余100M左右时改为30M每步，而且不要太快。这很重要，如果最后阶段步子太大、太快，很容易被OOM killer 迅速杀掉。
剩余物理内存用系统监视器或free看就行。
在我的机器（机械硬盘）上，如果关闭 earlyoom （systemctl stop earlyoom），它几乎 100% 能卡死。之前我用的测试方法（浏览器开很多页面、开虚拟机、android-studio）太繁琐了，还是这个好。
为了从卡死中恢复，可以这么做：在运行 memory_overcommit.cc 之前，先修改 /etc/sysctl.d/99-sysctl.conf （也可能是同一目录下的其它名字），把 kernel.sysrq=0 （或其它值）改为 kernel.sysrq=1 ；然后重启系统，或执行 sudo sysctl kernel.sysrq=1 立即生效。
在卡死后，按下组合键 alt + sysrq + r 然后按 alt + sysrq + f ，这是为了手工执行 oom killer。oom killer 可能要延迟几秒钟才执行，所以不要急不可耐的反复按 alt + sysrq + f ，以免杀掉很多无辜进程。sysrq 就是 print screen 键。