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

[korvin]

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

[qq316107934]

这个有可能是单页面内存超出上限了，一般是你下载的插件或者页面 JS 实现的有问题。

[zjsxwc]

linux 有 swap ，我小 server 都能靠 swap 来运行大内存软件，
windows 难道没有？

[tool2dx]

我写 BUG 的时候，也经常遇到。一般都是稍微底层的那些 indexed/wasm 之类的 JS 操作，会导致页面崩溃，提示信息就是 Out of memory （和 OP 一样，内存还有不少）

后面换一种写法就可以。

建议要不换 chrome portable 版本固定下来，要不就换浏览器。

[qq316107934]

@zjsxwc #2 虚拟内存 Windows 98 就有了，软件内的报错扯不到系统策略。

[AreYou0k]

你这虚拟设置内存小了, 你看已提交那里都满了. 之前刚搞过, 要么虚拟内存设置一点, 硬盘空间大一般直接 5-6 倍, 记得别放 c 盘, 要么加内存条咯

[zong400]

跑一下 aida 看看内存是不是不稳了，排除硬件就是 chrome bug

[sir283]

这种都是页面导致的问题，op 是不是写了存在内存泄漏的 bug ？导致 Out of Memory ，我之前也遇到过一些个人的小博客网站，也是动不动就内存蹦了的，单纯只是技术不佳，写了💩山代码导致 Out of Memory 问题。

[wanguorui123]

内存无法分配 Out of Memory

[zhhbstudio]

我是前端，写过这种 bug ，浏览器每个页签会限制内存，超了就报这个。

[leconio]

确定 64 位 Chrome 吧

[flynaj]

你已经提交的内存已经 40g 了，看看是什么软件占用了。用 procexp

[ysc3839]

要看已提交，实际只剩 41.6-40.9=0.7GB 可用。
Windows 预先分配内存必须要有足够的虚拟内存，分配后不使用不会占用物理内存，但是只要成功分配了，使用时就不会出现内存不足的情况。

[ysc3839]

@qq316107934 软件内的报错怎么扯不到系统策略？ Windows 的策略是预先分配内存必须要有足够的虚拟内存，既然虚拟内存不足，软件就会因为这个系统策略，分配内存失败后报错。

[kenvix]

× 还有 1/3 内存可用
√ 只剩 0.7G 能用

[nlzy]

@qq316107934 楼主的这个问题就是因为 Windows 系统不支持 overcommit 策略导致的，这种情况下换个别的应用照样分配不出内存。

回楼主：
正经的回复是：多开点 swap （ Windows 叫虚拟内存）就能解决。
不正经的回复是：换个好点的操作系统吧，能开 overcommit 的那种，比如 Linux 。

[epiphyllum]

进程“已提交”的内存超过“页面文件”和物理 RAM 大小的总和时就会出现这种情况（例如下图），这个问题是 Windows NT 的历史遗留问题造成的。
（很难想象 2024 年了 Windows 还在高度依赖虚拟内存，而且为了性能实际被 swap 进磁盘的页面其实很少，实在是浪费磁盘空间）

解决方法：

1. 在任务管理器里面找到“详细信息”选项卡，右键点击列标题区域（例如“名称”列），选择“选择列”。
把“已提交大小”勾上，排查一下哪些进程的已提交大小过高。

2. 还有一种情况是：楼主的系统分区可能空间不足，或者楼主修改了系统的虚拟内存相关设置。
（因为 Windows 默认会自动管理虚拟内存/页面文件的大小。当系统“已提交”大小达到系统提交限制的 90% 时，系统管理的页面文件会自动扩展到物理内存的 3 倍，但不会超过卷大小的 1/8 ）

- 如果是这种情况并且磁盘空间足够的话，可以 Win+R 运行`sysdm.cpl`（控制面板->系统属性），修改系统设置让 Windows 多分配些虚拟内存（或者设为系统自动管理）

[qq316107934]

统一回复楼上，学到了

[COW]

Chrome 就是个内存吞噬者，Windows 上内存处理这块甚至不如 Edge ，换了 Mac 或者 Linux 桌面，也是一样的吃内存，目前只能缓解。建议加大物理内存，少开 tab 页，硬件加速关了，装一个 OneTab 之类的插件，不用的标签页先收起来，另外部分网站设计有问题会不断消耗内存也要注意下。

[korvin]

感谢各位，学到知识了，我好像之前确实有调整过虚拟内存的设置，，也的确是以前没这个问题，突然某天开始出现的，现在按这个说法猜测可能是我调了虚拟内存之后出现的问题。周一回公司按你说的方案试试 @epiphyllum #16

[ysc3839]

@epiphyllum 虽然但是 macOS 更为依赖虚拟内存，甚至被怀疑影响 SSD 寿命 https://v2ex.com/t/851563
两大占据绝对市场份额的桌面操作系统都选择依赖虚拟内存，很难说这个设计到底是对还是错。
不过 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 。

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