Windows 还有 1/3 内存可用， Chrome 经常报内存不足（Out of Memory）

[korvin]

内在还剩余 1/3 ，9G 左右水平，Chrome 开了不到 20 个标签页，最近经常碰到 Chrome 报内存不足/浏览器无响应卡死（光标转圈，等待几分钟不恢复，只能结束进程）。是我电脑哪方面设置有问题吗？

[kokutou]

页面文件默认设置 Windows 管理的大小=内存大小加上磁盘空闲空间大小。

Windows 真的是默认设置就行了 微软真不是啥都不懂

[kenvix]

@epiphyllum #16 本质上是 Windows 不会像 unix 那样超前分配内存，不使用 OOM Killer 保证业务进程不会意外死亡，而是在内存不足的时候立即快速失败

[epiphyllum]

@ysc3839 #20
我觉得依赖虚拟内存技术（内存压缩/分页文件/SWAP ）本身没问题，毕竟像 提高多任务能力/保留兼容性/压缩硬件成本 之类的好处都能给用户带来实实在在的收益。

问题其实还是操作系统在“依赖虚拟内存”的过程中容易出差错（依赖 SWAP/页面文件时没好好设计导致的），就像这里因为 Windows 缺乏灵活的"overcommit"设计导致了用户的程序在 RAM 仍有空闲的情况下崩溃； 系统没管理好类似"swappiness"这样的参数在当年让 macOS 用户的硬盘被大量异常写入、让 Windows 的分页文件占着大量存储空间却实际只有很一小部分被利用…

但是 Chrome 确实是真的出了名的吃内存（

[v2tudnew]

@epiphyllum
手机我可以接受 overcommit ，台式机我后台挂着游戏、大型任务你给我杀了，那我真要跳脚了。

觉得存储空间占用大你可以启用内存压缩和自定义页面文件大小，比如设置 1GB-64GB 。
这样只会在内存压缩也无法满足的情况下才存入硬盘，而且实际 pagefile.sys 大小也是实际写入后才变大的。

[epiphyllum]

@v2tudnew #24

1. overcommit 在这篇帖子的场景下其实恰恰反而可以让操作系统上的进程更稳定，允许程序向操作系统“提交”多于虚拟内存+物理 RAM 大小的内存更像是一种宽恕，而不是严格的限制。
（要不然掌管服务器操作系统半壁江山的 Linux 上若是经常让关键业务和后台进程经常挂掉的话，那老板/员工/客户都得难受了）
（而且 Linux 上 overcommit 、oom 行为、swap/zram 都是有很多选项可以按自己需求灵活调整的）


2. 以 Linux 为例，杀死进程的并不是 overcommit 特性本身，而是 oom-killer 和内存分配失败导致的程序崩溃。

此外，假如真到了像是内存被占满必须得靠 oom-killer 出马杀几个进程祭天的场景，Windows 上“严格的限制”并不一定能保证后台挂着的游戏和大型任务能安稳地运行。
例如我在#16 楼发的截图：在“已提交”紧缺的时候，"System Informer"这种在后台挂着当资源监视器的小工具也会崩溃、Windows 控制面板也逃不过卡死。关键是它们崩溃时物理内存根本没占满甚至还有大量空闲。对于内存释放分配更频繁、空间请求和占用都更多的游戏和大型任务这很可能会更糟，毕竟进程的 Commit Charge 是不会小于实际内存用量的。

[v2tudnew]

@epiphyllum
你那张图无非是虚拟内存占满了，肯定是崩溃的，我上面已经说了你可以调大页面文件，实际它不会立即写入。
这种情况不是和 overcommit 一样的效果，没有 oom-killer 的情况下 Linux 内存占满它就不会崩了？
所以关键的还是 oom-killer 杀死进程，但普通人如何配置哪些进程被杀死？
像手机游戏就经常被杀，加大学习成本研究守护方法。
默认 Windows 是所有分区分配页面文件的，自己不调没这个问题。

[epiphyllum]

@v2tudnew #26
1.
> 你那张图无非是虚拟内存占满了，肯定是崩溃的，我上面已经说了你可以调大页面文件，实际它不会立即写入。
图上并不是虚拟内存占满了。程序要操作系统承诺(commit)大量内存≠进程真的要利用那么多内存（包括物理 RAM 和各种形式的虚拟内存）
例如：


2.
> 这种情况不是和 overcommit 一样的效果，没有 oom-killer 的情况下 Linux 内存占满它就不会崩了？
“Linux 内存占满后会不会崩”我不敢打包票，毕竟哪怕我是神仙我也不能超过物理限制；但这里的多个例子已经展示了 Windows 上物理 RAM 和虚拟内存两个都没占满甚至还有大量空闲的情况下就有进程崩了。overcommit 是灵活的变通手段不是死板杀进程的限制。

3.
> 所以关键的还是 oom-killer 杀死进程，但普通人如何配置哪些进程被杀死？
同上，Linux 出现 oom-killer 是「内存真占满了」的极端情况，Windows 上离极端情况还差得远的时候就开始拒绝内存申请。保不住后台的“小工具”，更不一定能保住高资源占用率的关键应用。
况且能给用户更大的选择权总归是好的。


4.
> 像手机游戏就经常被杀，加大学习成本研究守护方法。

拿移动端来比就没意思了。手机为了便携就必须在硬件规格上妥协（有限得多的电源供应、算力和内存大小），必须在续航能力/流畅度上想办法优化，这是操作系统有意而为之的设计。

以 Android 为例：当年 Android 2.3/4.x/5.x 的年代用户还得自己开黑阈/阻止运行/绿色守护主动关闭杀后台进程，要不然 xx 手机卫士/xx 手机管家/某宝/某些即时通讯软件/xx 手机助手怕是得在手机里闹翻天。
如今 Google 和国产手机厂商都学聪明了，手机硬件配置不断升级的今天，各种 XXUI/XXOS 的后台进程策略反而比当年严格得多。某三字购物软件更是靠“挖 CVE”来给自己提权保活。如今杀后台的可能不是 oom-killer ，更可能是手机自带的“系统管家”和操作系统的电池优化特性。


5.
> 默认 Windows 是所有分区分配页面文件的，自己不调没这个问题。
Windows 并不会默认在所有分区上创建 pagefile.sys 。

[v2tudnew]

@epiphyllum

1.
>图上并不是虚拟内存占满了

你提交内存都 61.9/62.6GB 还说没满，你这个工具我不懂，但 Windows 只认这个提交（虚拟）内存。
你要是搞个 40/62 GB 崩了还有点说服力

2.
>overcommit 是灵活的变通手段

我反正不能接受 100/20 GB 这种奇怪的虚拟内存使用量，而且没有杀死进程的手段情况下崩溃的风险很大。

3.
>Windows 上离极端情况还差得远的时候

你这前提条件就不成立，至于要选择权你得找微软。

4.
你不想比反正手机杀进程的事实也在那

5.
> Windows 并不会默认在所有分区上创建 pagefile.sys 。

这点确实是我的失误，默认只分配系统盘。