专栏首页前端皮小蛋项目构建内存溢出了?看看 Node 内存限制

项目构建内存溢出了?看看 Node 内存限制

背景

在之前的一篇文章中, 我们遇到了一个项目在构建时内存溢出的问题。

当时的解决方案是: 直接调大 node 的内存限制,避免达到内存上限。

今天听同事分享了一个新方法,觉得不错, 特此记录, 顺便分享给大家。

正文

报错示意图:

提示已经很明显:Javascript Heap out of memory.

看到内存溢出这个关键字,我们一般都会考虑到是因为 Node.js 内存不够导致的。

但 Node 进程的内存限制会是多少呢?

在网上查阅了到如下描述:

Currently, by default V8 has a memory limit of 512mb on 32-bit systems, and 1gb on 64-bit systems. The limit can be raised by setting --max-old-space-size to a maximum of ~1gb (32-bit) and ~1.7gb (64-bit), but it is recommended that you split your single process into several workers if you are hitting memory limits.

翻译一下:

当前,默认情况下,V8在32位系统上的内存限制为512mb,在64位系统上的内存限制为1gb。

可以通过将--max-old-space-size设置为最大〜1gb(32位)和〜1.7gb(64位)来提高此限制,但是如果达到内存限制, 建议您将单个进程拆分为多个工作进程

如果你想知道自己电脑的内存限制有多大, 可以直接把内存撑爆, 看报错。

运行如下代码:

// Small program to test the maximum amount of allocations in multiple blocks.
// This script searches for the largest allocation amount.

// Allocate a certain size to test if it can be done.
function alloc (size) {
  const numbers = size / 8;
  const arr = []
  arr.length = numbers; // Simulate allocation of 'size' bytes.
  for (let i = 0; i < numbers; i++) {
    arr[i] = i;
  }
  return arr;
};

// Keep allocations referenced so they aren't garbage collected.
const allocations = []; 

// Allocate successively larger sizes, doubling each time until we hit the limit.
function allocToMax () {
  console.log("Start");

  const field = 'heapUsed';
  const mu = process.memoryUsage();

  console.log(mu);

  const gbStart = mu[field] / 1024 / 1024 / 1024;

  console.log(`Start ${Math.round(gbStart * 100) / 100} GB`);

  let allocationStep = 100 * 1024;

  // Infinite loop
  while (true) {
    // Allocate memory.
    const allocation = alloc(allocationStep);
    // Allocate and keep a reference so the allocated memory isn't garbage collected.
    allocations.push(allocation);
    // Check how much memory is now allocated.
    const mu = process.memoryUsage();
    const gbNow = mu[field] / 1024 / 1024 / 1024;

    console.log(`Allocated since start ${Math.round((gbNow - gbStart) * 100) / 100} GB`);
  }

  // Infinite loop, never get here.
};

allocToMax();

不出意外, 你将喜提如下报错:

我的电脑是 Macbook Pro masOS Catalina 16GB,Node 版本是 v12.16.1,这段代码大概在 1.6 GB 左右内存时候抛出异常。

那我们现在知道 Node Process 确实是有一个内存限制的, 那我们就来增大它的内存限制再试一下。

node --max-old-space-size=6000 来运行这段代码,得到如下结果:

内存达到 4.6G 的时候也溢出了。

你可能会问, node 不是有内存回收吗?这个我们在下面会讲。

使用这个参数:node --max-old-space-size=6000, 我们增加的内存中老生代区域的大小,比较暴力。

就像上文中提到的:如果达到内存限制, 建议您将单个进程拆分为多个工作进程

这个项目是一个 ts 项目,ts 文件的编译是比较占用内存的,如果把这部分独立成一个单独的进程, 情况也会有所改善。

因为 ts-loader 内部调用了 tsc,在使用 ts-loader 时,会使用 tsconfig.js配置文件。

当项目中的代码变的越来越多,体积也越来越庞大时,项目编译时间也随之增加。

这是因为 Typescript 的语义检查器必须在每次重建时检查所有文件

ts-loader 提供了一个 transpileOnly 选项,它默认为 false,我们可以把它设置为 true,这样项目编译时就不会进行类型检查,也不会输出声明文件。

对一下 transpileOnly 分别设置 falsetrue 的项目构建速度对比:

  • 当 transpileOnly 为 false 时,整体构建时间为 4.88s.
  • 当 transpileOnly 为 true 时,整体构建时间为 2.40s.

虽然构建速度提升了,但是有了一个弊端: 打包编译不会进行类型检查

好在官方推荐了这样一个插件, 提供了这样的能力:fork-ts-checker-webpack-plugin

官方示例的使用也非常简单:

const ForkTsCheckerWebpackPlugin = require('fork-ts-checker-webpack-plugin')

module.exports = {
  ...
  plugins: [
    new ForkTsCheckerWebpackPlugin()
  ]
}

在我这个实际的项目中,vue.config.js 修改如下:

configureWebpack: config => {
 // get a reference to the existing ForkTsCheckerWebpackPlugin
 const existingForkTsChecker = config.plugins.filter(
   p => p instanceof ForkTsCheckerWebpackPlugin,
 )[0];

// remove the existing ForkTsCheckerWebpackPlugin
// so that we can replace it with our modified version
 config.plugins = config.plugins.filter(
   p => !(p instanceof ForkTsCheckerWebpackPlugin),
 );

 // copy the options from the original ForkTsCheckerWebpackPlugin
 // instance and add the memoryLimit property
 const forkTsCheckerOptions = existingForkTsChecker.options;
 
 forkTsCheckerOptions.memoryLimit = 4096;
 
 config.plugins.push(new ForkTsCheckerWebpackPlugin(forkTsCheckerOptions));
}

修改之后, 构建就成功了。

关于Node垃圾回收

在 Node.js 里面,V8 自动帮助我们进行垃圾回收, 让我们简单看一下V8中如何处理内存。

一些定义

  • 常驻集大小:是RAM中保存的进程所占用的内存部分,其中包括:
    1. 代码本身
  • stack:包含原始类型和对对象的引用
  • 堆:存储引用类型,例如对象,字符串或闭包
  • 对象的浅层大小:对象本身持有的内存大小
  • 对象的保留大小:删除对象及其相关对象后释放的内存大小

垃圾收集器如何工作

垃圾回收是回收由应用程序不再使用的对象所占用的内存的过程。

通常,内存分配很便宜,而内存池用完时收集起来很昂贵。

如果无法从根节点访问对象,则该对象是垃圾回收的候选对象,因此该对象不会被根对象或任何其他活动对象引用。

根对象可以是全局对象,DOM元素或局部变量。

堆有两个主要组成部分,即 New SpaceOld Space

新空间是进行新分配的地方。

在这里收集垃圾的速度很快,大小约为1-8MB

留存在新空间中的物体被称为新生代

在新空间中幸存下来的物体被提升的旧空间-它们被称为老生代

旧空间中的分配速度很快,但是收集费用很高,因此很少执行。

Node 垃圾回收

Why is garbage collection expensive?

The V8 JavaScript engine employs a stop-the-world garbage collector mechanism.

In practice, it means that the program stops execution while garbage collection is in progress.

通常,约20%的年轻一代可以存活到老一代,旧空间的收集工作将在耗尽后才开始。

为此,V8引擎使用两种不同的收集算法

  1. Scavenge: 速度很快,可在新生代上运行,
  2. Mark-Sweep: 速度较慢,并且可以在老生代上运行。

篇幅有限,关于v8垃圾回收的更多信息,可以参考如下文章:

  1. http://jayconrod.com/posts/55/a-tour-of-v8-garbage-collection
  2. https://juejin.cn/post/6844903878928891911
  3. https://juejin.cn/post/6844903859089866760

总结

小小总结一下,上文介绍了两种方式:

  1. 直接加大内存,使用: node --max-old-space-size=4096
  2. 把一些耗内存进程独立出去, 使用了一个插件: fork-ts-checker-webpack-plugin

希望大家留个印象, 记得这两种方式。

好了, 内容就这么多, 谢谢。

相关资料

  1. https://www.cloudbees.com/blog/understanding-garbage-collection-in-node-js/
  2. http://jayconrod.com/posts/55/a-tour-of-v8-garbage-collection
  3. https://blog.risingstack.com/finding-a-memory-leak-in-node-js/

本文分享自微信公众号 - 前端皮小蛋(gh_e69260c16440),作者:南山皮小蛋

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2021-04-23

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • Java堆内存又溢出了!看大师如何防范

    JAVA堆内存管理是影响性能主要因素之一。 堆内存溢出是JAVA项目非常常见的故障,在解决该问题之前,必须先了解下JAVA堆内存是怎么工作的。

    慕容千语
  • Vue内存溢出问题解决方法

    引起内存泄漏的原因有不少,本文就介绍webpack 运行 npm run build 内存溢出 JavaScript heap out of memory内存溢...

    前端逗逗飞
  • angular打包报错内存溢出 nodejs 执行失败报错 “JavaScript heap out of memory” 的解决办法

    报错信息很直观地指出是内存溢出了。是什么导致了内存溢出呢?其根本原因在于 nodejs 默认限制了最大可使用的内存大小。

    用户1437675
  • Jenkins前端打包内存溢出问题

    公司项目vue构建,体积比较庞大,在Jenkins上构建时,有新的内容提交时,第一次npm run build必失败,报内存溢出错误

    全栈程序员站长
  • 极致性能(1):以NUMA为起点

    一个[合格的]Oracle DBA在安装数据库的时候,通常都会按要求关闭NUMA(MOS:Disable NUMA At OS Level (Doc ID 21...

    boypoo
  • MySQL的实战系列:大字段如何优化

    除特别注明外,本站所有文章均为慕白博客原创,转载请注明出处来自https://geekmubai.com/programming/747.html

    慕白
  • 调用OR-Tools求解器求解网络流问题

    大家好,小编最近新学了一个求解器OR-Tools,今天给大家介绍一下如何用OR-Tools求解器求解网络流问题中的最大流问题和 最小费用流问题。

    用户1621951
  • 真香!20张图揭开「队列」的迷雾,一目了然

    首先我们联想一下链表,在单链表中,我们只能对他的链表表尾进行插入,对链表的表头进行结点的删除,这样强限制性的链表,就是我们所说的队列。

    C语言与CPP编程
  • MySQL提升笔记(4)InnoDB存储结构

    这一节本来计划开始索引的学习,但是在InnoDB存储引擎的索引里,存在一些数据存储结构的概念,这一节先了解一下InnodDB的逻辑存储结构,为索引的学习打好基础...

    三分恶
  • Vulnhub靶机渗透-Tr0ll:2

    既然web没什么突破口,那么我们还是从ftp试试看,考虑生成个社工字典,根据WEB给出的Author以及Editor:

    HACK学习
  • 数据结构知否知否系列之 — 线性表的顺序与链式存储篇(8000 多字长文)

    线性表是由 n 个数据元素组成的有限序列,也是最基本、最简单、最常用的一种数据结构。

    五月君
  • Presto内存调优及原理(基础篇)

    Presto是一个开源的分布式SQL查询引擎,适用于交互式分析查询,数据量支持GB到PB字节。Presto支持在线数据查询,包括Hive, Cassandra,...

    用户1263954
  • Presto内存调优及原理(基础篇)

    Presto是一个开源的分布式SQL查询引擎,适用于交互式分析查询,数据量支持GB到PB字节。

    sundyxiong
  • 缓冲区溢出漏洞可导致内核崩溃,苹果多款操作系统均受影响

    国外大神Kevin Backhouse刚刚放出了一篇博文,对苹果操作系统内核中发现的堆缓冲区溢出漏洞(CVE-2018-4407)进行了一番解构。

    FB客服
  • Node.js Stream 背压 — 消费端数据积压来不及处理会怎么样?

    Stream 在 Node.js 中是一个被广泛应用的模块,流的两端可读流、可写流之间通过管道链接,通常写入磁盘速度是低于读取磁盘速度的,这样管道的两端就会产生...

    五月君
  • ConsurrentDictionary并发字典知多少?

    在上一篇文章你真的了解字典吗?一文中我介绍了Hash Function和字典的工作的基本原理. 有网友在文章底部评论,说我的Remove和Add方法没有考虑线...

    码农阿宇
  • 「项目实战」优化项目构建时间

    之前本地构建时间挺长的,初次启动要三次分钟, 后面我配置了 Vite, 本地启动时间降低到了 20s 左右,感兴趣的可以移步我这篇文章:

    皮小蛋
  • ES配置详解和主从搭建

    付威
  • MacOS再次出现漏洞,号称牢不可破的系统也有弱点

    本文讲述了我在苹果的macOS系统内核中发现的几个堆栈和缓冲区溢出漏洞,苹果官方将这几个漏洞归类为内核中的远程代码执行漏洞,因此这些漏洞的威胁级别非常高。攻击者...

    FB客服

扫码关注云+社区

领取腾讯云代金券