经过测试好几次，都会这样的

交换空间又不能代替物理内存，物理内存占满了的时候系统不稳定是很正常的

关键以前不是这样的，现在是他一旦用完 一秒钟不要就直接卡死，不带换气的

这没有什么可比性，到了 OOM 的阶段你就很难控制接下来会出什么意外：如果 OOM killer 杀掉的进程并不很关键，系统可能恢复正常；如果 OOM killer 杀了关键进程，卡死就不奇怪了。

EDIT：卡死的情况更可能是没有触发 OOM killer，系统正在拼命地将内存中的数据往交换空间中挤，这样很容易造成系统无响应

这样不好的，可以达到一定比例 限制吃内存的速度或者其它良好的 设计，主要是他毫无预警的直接卡死

OOM killer 是有必要的，但这不代表 OOM 之前没有其他释放内存的措施。交换空间就是一个很重要的缓冲机制，但它对于内存突然占满的情况也没什么作用，反而会延迟 OOM killer 启动的时机，造成更加严重的卡顿。系统层面能管到的就只有这么多了，其他的就只能靠应用的开发者自觉以及用户对应用的选择了。

并非任何被占用的物理内存都可以被交换或者回收（指 page cache）。所以当不可交换、不可回收的内存等于物理内存大小时，确实会卡死，即使此时交换空间还有剩余。

你说“以前不是这样的”应该不准确。不过，如何确定真正的“内存耗尽”，也没那么简单。

内核的 OOM killer 基本上没什么用，建议安装 earlyoom 来代替。

参考我以前的帖子：

https://bbs.deepin.org/zh/post/141744?id=141744

我的机器就是这样，没有设置任何交换分区和文件。经常出现gcc编译，内存直接飙到100%，此时鼠标无法移动或移动非常缓慢，系统基本无法操作，只能重启。非常影响使用，希望重点改善。

swap 还是有必要设置的，另外可以试着减小编译时所用的线程数

好东西，已安装

free看看swap有没有启用，最近在系统服务发现了zram这个功能，可以试试

我在20.1可以开4个虚拟机同时打开，在20.2开俩个就跑到100%死机了，这个很明显的区别

该不会是 deepin 自作聪明同时开了 zswap 和 zram，或者把默认的 snappiness 设置得太小吧

大佬好久不见了。

swappiness
Ubuntu Feisty默认的vm.swappiness值是60,这一默认值已经很合适了。但你可以改小一些降低swap的加载，系统性能会有一点点的提升
输入：
代碼:
sysctl -q vm.swappiness

你会看到值是60， 更改:
代碼:
sudo sysctl vm.swappiness=10

这样你就将值由60改为10,这可以大大降低系统对于swap的写入，建议内存为512m或更多的朋友采用此方法。如你你发现你对于swap的使用极少，可以将值设为0。这并不会禁止你对swap的使用，而是使你的系统对于swap的写入尽可能的少，同时尽可能多的使用你的实际内存。这对于你在切换应用程序时有着巨大的作用，因为这样的话它们是在物理内存而非swap分区中。
如果你想永久得改变这一值，你需要更改 sysctl.conf 文件：
代碼:
sudo kate /etc/sysctl.conf

添加：
vm.swappiness=10
到末行，需要重启生效。
我2G内存， 把它设置为0

估计是想提升系统性能，结果呢，太用内存啦，物理内存不够他用

用5.11.13的