如何为chrome-aws-lambda中的Chromium分配更多可用内存？

一、优先排查本地Docker容器的内存配额问题 #

你在template.yaml里写的MemorySize: 4096配置，本地跑SAM的时候根本不会生效。

• SAM本地服务是依托本地Docker daemon运行的，默认给容器分配的内存完全继承Docker Desktop的全局资源上限，不会自动读取模板里的函数内存参数。很多人踩过这个坑：哪怕模板里设了4G内存，本地Docker默认只给2G甚至更少的内存配额，Chrome刚启动就触发OOM被内核直接杀掉，自然会报Target closed的错。
• 解决方法很简单：启动SAM本地服务的时候显式传内存参数，跑命令：sam local start-api --memory 4096，强制给本地模拟的Lambda容器分4G内存；如果还是内存不够，可以在Docker Desktop的资源设置里，给Docker服务多分配点全局可用内存，避免容器和本地其他进程抢内存。

二、补全缺失的Chrome低内存启动参数 #

只加个--disable-dev-shm-usage根本压不住Chrome的内存峰值，这也是很多人加了参数还是报错的核心原因。在launch的args数组里，必须补几个Lambda环境专属的低内存运行参数：

• --single-process：强制Chrome用单进程跑，别拆分多进程，不然几个进程叠起来的内存峰值很容易爆容器配额
• --no-zygote：配合单进程模式用，把Chrome预生成fork子进程的逻辑关掉，省掉不必要的内存占用
• --js-flags=--max-old-space-size=2048：把V8引擎的堆内存上限锁到2G，防止JS堆不受控膨胀吃满所有内存
  改完的args部分参考：

args: [
  ...chromium.args, 
  `--proxy-server=${proxyUrl}`, 
  '--disable-dev-shm-usage',
  '--single-process',
  '--no-zygote',
  '--js-flags=--max-old-space-size=2048'
]

三、修正代码逻辑，补上崩溃容错 #

• 你现在的逻辑是点完提交按钮，立刻就去等页面上的#myDiv元素。但如果点按钮之后会触发页面跳转，就会出现等待和导航的竞态：还没等导航完成就开始等元素，很容易因为页面上下文切换触发Chrome崩溃。可以把点击和等待导航的逻辑改成并行执行，用Promise.all同时跑点击动作和导航等待，等页面完全加载完再去等元素，减少异常概率。
• 必须给浏览器实例加断开事件监听：一旦触发disconnected事件，就说明Chrome已经意外挂了，这时候要重新初始化浏览器实例，别硬对着已经死掉的页面调接口，不然百分百报那个Target closed的协议错。
• 给waitForSelector显式设个合理的超时时间（比如30秒），别让它一直无限等，Chrome真挂了之后它还傻等半天，徒增排查成本。

四、排查版本错配的坑 #

你现在用的chrome-aws-lambda:22层是很老的版本了，这个版本本身就有不少内存泄漏的问题：

• 一定要确保本地node_modules里装的chrome-aws-lambda版本，和Lambda Layer里打包的版本完全一致。很多人本地装了最新版的依赖，结果线上Layer还是老版本，两边通信协议对不上，直接就断连报Target closed。
• 如果调完内存还是跑不动，就换个和nodejs14.x适配的较新稳定版层，老版本的Chrome启动时会多开不必要的GPU进程、冗余子进程，光这些没用的进程就能占近1G内存，换成新版本直接就能释放出来。

内容的提问来源于stack exchange，提问作者Philipp Chapkovski