NodeJS 节点j16和节点j14之间的最大旧空间大小是否发生变化?

gudnpqoy  于 2022-12-18  发布在  Node.js
关注(0)|答案(1)|浏览(124)

我们使用--max-old-space-size=8192来运行完整的E2 E jest 26测试和npm测试。

node --max-old-space-size=8192 node_modules/jest/bin/jest --runInBand --coverage --detectOpenHandles --logHeapUsage --no-cache

我们升级到节点16.14.2,突然测试停止在4G,在Windows和Ubuntu 20.04.4 LTS下使用OOM。
与节点17.8.0的行为相同
我切换回节点14.18.1,并使用进程资源管理器看到下面的性能图。

对于节点16,我在E2 E测试开始时在4G下得到OOM。

<--- Last few GCs --->

[14184:00000277700CA440]  1097059 ms: Mark-sweep (reduce) 2799.4 (3161.8) -> 2798.8 (3123.2) MB, 1520.8 / 0.4 ms  (average mu = 0.099, current mu = 0.064) last resort GC in old space requested
[14184:00000277700CA440]  1098475 ms: Mark-sweep (reduce) 2798.8 (3123.2) -> 2798.7 (3116.2) MB, 1416.0 / 1.6 ms  (average mu = 0.053, current mu = 0.000) last resort GC in old space requested

我用nvm-windows在节点版本之间切换。
这些包都是用npm从node 16安装的,它们在node 14上运行得很好。
尝试了其他几个空间相关的v8选项,但对节点16和17没有积极影响。
还不想打开github/node的问题,因为它不容易隔离。
有什么建议吗?
更新:
我在节点16 V8中的第一个深入发现是--huge-max-old-generation-size现在默认为true。
这将内存限制为4G。
另请参见https://github.com/v8/v8/commit/b2f75b008d14fd1e1ef8579c9c4d2bc7d374efd3
和堆::最大旧代大小和堆::堆大小来自物理内存
据我所知,最大旧空间被限制在4G以内(至少当巨大的旧空间打开时)
现在,设置--no-huge-max-old-generation-size--max-old-space-size=8192仍然没有效果,并且再次在4G下进行OOM。
更新2:
我跟踪了v8堆统计信息,并在4G的OOM之前看到了来自v8.getHeapSpaceStatistics()和v8.getHeapStatistics()的信息

total_heap_size               : 3184 MB
total_heap_size_executable    : 127 MB
total_physical_size           : 3184 MB
total_available_size          : 9162 MB
used_heap_size                : 2817 MB
heap_size_limit               : 12048 MB
malloced_memory               : 2 MB
peak_malloced_memory          : 44 MB
does_zap_garbage              : 0 MB
number_of_native_contexts     : 0 MB
number_of_detached_contexts   : 0 MB
read_only_space               : size : 0 MB, used: 0 MB, avail: 0 MB, phy: 0 MB
old_space                     : size : 2425 MB, used: 2111 MB, avail: 268 MB, phy: 2425 MB
code_space                    : size : 127 MB, used: 110 MB, avail: 8 MB, phy: 127 MB
map_space                     : size : 44 MB, used: 39 MB, avail: 4 MB, phy: 44 MB
large_object_space            : size : 555 MB, used: 541 MB, avail: 0 MB, phy: 555 MB
code_large_object_space       : size : 0 MB, used: 0 MB, avail: 0 MB, phy: 0 MB
new_large_object_space        : size : 0 MB, used: 0 MB, avail: 15 MB, phy: 0 MB
new_space                     : size : 32 MB, used: 13 MB, avail: 2 MB, phy: 32 MB

<--- Last few GCs --->

[7940:000001B87F118E70]   546939 ms: Mark-sweep (reduce) 2774.1 (3123.5) -> 2773.6 (3084.7) MB, 498.6 / 0.3 ms  (average mu = 0.080, current mu = 0.044) last resort GC in old space requested
[7940:000001B87F118E70]   547453 ms: Mark-sweep (reduce) 2773.6 (3084.7) -> 2773.4 (3077.2) MB, 513.2 / 0.3 ms  (average mu = 0.040, current mu = 0.000) last resort GC in old space requested

<--- JS stacktrace --->

更新3:
升级到jest 27.5.1,没有区别。节点14很好,但节点16/17卡在4G,而他们的堆统计报告大量的可用空间。

aiazj4mn

aiazj4mn1#

目前唯一的解决方案是使用节点16.10.0运行jest测试
这个问题在github.com/facebook/jest/issues/11956中讨论过,但建议的jest配置更改似乎都不起作用。
大型jest测试套件仍然会导致内存泄漏(或内存限制)的发生。

相关问题