【问题标题】:JavaScript heap out of memory when deploying to heroku - Nestjs Application API request for AWS S3 delete object部署到heroku时JavaScript堆内存不足-AWS S3删除对象的Nestjs应用程序API请求
【发布时间】:2020-08-14 22:10:35
【问题描述】:

NPM 模块:“@ntegral/nestjs-s3”:“^1.0.2”,

Rest API 应用:Nest js

部署到 Heroku 时出错的服务代码

async deleteImage(filename: string): Promise<{message: string}> {
        if(filename !== undefined || filename !== null) {
            const param = {
                Bucket: 'myblogbucket1',
                Key: `authorProfile/${filename}` 
            }
            this.s3.deleteObject(param)
            return {message: `deleted ${filename}`};
        }

以及处理此代码的控制器:

@Delete('/deletefile/:filename')
    async deleteOldImage(
        @Param('filename') filename: string
    ): Promise<{message: string}> {
        return this.profileService.deleteImage(filename)
    }

这是 Nestjs 应用程序中配置文件模块中的模块导入设置

S3Module.forRoot({
      accessKeyId: process.env.AWS_ACCESS_KEY_ID,
      secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY
    }),

一旦我使用

构建了这个应用程序
npm run start:dev

当我通过邮递员将其发送到服务器时,这很好用。在 AWS S3 存储桶中,文件被删除。

类似:

http://localhost:3000/profile/deletefile/131bc7c5-d6e3-4cdf-bdf7-b55448a0f14f.jpeg

但是当我尝试将此代码推送到 heroku 时,它会出现构建错误。

这是堆栈

<--- Last few GCs --->
2020-04-30T12:08:43.064905+00:00 app[web.1]:
2020-04-30T12:08:43.064908+00:00 app[web.1]: [58:0x342e9e0]    12037 ms: Mark-sweep 255.5 (257.0) -> 255.0 (257.3) MB, 331.4 / 0.0 ms  (average mu = 0.138, current mu = 0.027) allocation failure scavenge might not succeed
2020-04-30T12:08:43.064908+00:00 app[web.1]: [58:0x342e9e0]    12517 ms: Mark-sweep 255.6 (257.3) -> 255.2 (257.8) MB, 469.7 / 0.0 ms  (average mu = 0.071, current mu = 0.022) allocation failure scavenge might not succeed
2020-04-30T12:08:43.064909+00:00 app[web.1]:
2020-04-30T12:08:43.064909+00:00 app[web.1]:
2020-04-30T12:08:43.064909+00:00 app[web.1]: <--- JS stacktrace --->
2020-04-30T12:08:43.064909+00:00 app[web.1]:
2020-04-30T12:08:43.064910+00:00 app[web.1]: ==== JS stack trace =========================================
2020-04-30T12:08:43.064910+00:00 app[web.1]:
2020-04-30T12:08:43.064911+00:00 app[web.1]: 0: ExitFrame [pc: 0x13c5b79]
2020-04-30T12:08:43.064911+00:00 app[web.1]: 1: StubFrame [pc: 0x134ca01]
2020-04-30T12:08:43.064912+00:00 app[web.1]: Security context: 0x0a541a0408d1 <JSObject>
2020-04-30T12:08:43.064913+00:00 app[web.1]: 2: parseStatement(aka parseStatement) [0x26ae695381c1] [/app/node_modules/typescript/lib/typescript.js:~23390] [pc=0x33711f1a8be3](this=0x1040d0c004b1 <undefined>)
2020-04-30T12:08:43.064914+00:00 app[web.1]: 3: parseList(aka parseList) [0x26ae69535141] [/app/node_modules/typescript/lib/typescript.js:~20041] [pc=0x33711f1be0c0](this=0x1040d0c004b1 <undefined>,1,0x26a...
2020-04-30T12:08:43.064914+00:00 app[web.1]:
2020-04-30T12:08:43.064921+00:00 app[web.1]: FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory        
2020-04-30T12:08:43.065228+00:00 app[web.1]:
2020-04-30T12:08:43.078709+00:00 app[web.1]: Writing Node.js report to file: report.20200430.120843.58.0.001.json
2020-04-30T12:08:43.078710+00:00 app[web.1]: Node.js report completed
2020-04-30T12:08:43.078711+00:00 app[web.1]: 1: 0xa09830 node::Abort() [node]
2020-04-30T12:08:43.078711+00:00 app[web.1]: 2: 0xa09c55 node::OnFatalError(char const*, char const*) [node]
2020-04-30T12:08:43.078712+00:00 app[web.1]: 3: 0xb7d71e v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [node]
2020-04-30T12:08:43.078713+00:00 app[web.1]: 4: 0xb7da99 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [node]
2020-04-30T12:08:43.078713+00:00 app[web.1]: 5: 0xd2a1f5  [node]
2020-04-30T12:08:43.078713+00:00 app[web.1]: 6: 0xd2a886 v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector) [node]
2020-04-30T12:08:43.081317+00:00 app[web.1]: 7: 0xd37105 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [node]
2020-04-30T12:08:43.081318+00:00 app[web.1]: 8: 0xd37fb5 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
2020-04-30T12:08:43.081319+00:00 app[web.1]: 9: 0xd3aa6c v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
2020-04-30T12:08:43.081320+00:00 app[web.1]: 10: 0xd0163b v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationType, v8::internal::AllocationOrigin) [node]
2020-04-30T12:08:43.081320+00:00 app[web.1]: 11: 0x104300e v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [node]
2020-04-30T12:08:43.082018+00:00 app[web.1]: 12: 0x13c5b79  [node]
2020-04-30T12:08:43.174500+00:00 app[web.1]: Aborted

现在,一旦我删除了这个服务方法和控制器,部署就会成功。这意味着它不是与 Heroku Dyno 或内存限制相关的错误。我的应用也只有 58 Mb,我有 512。

搜索 2 天后,我发现我的方法中存在某种无限循环,因此在部署到 heroku 时,此构建会崩溃。正如它所说的JavaScript堆内存不足。但是我无法找到问题,因为当我在 localhost:3000 上启动此应用程序时它工作正常。而且我是后端新手。

任何人都可以更正此代码,以便它也可以无错误地部署并在 Heroku 上运行。请记住,此代码在本地主机上运行没有任何问题,并且应用程序也在我的 PC 上构建。

【问题讨论】:

    标签: javascript amazon-web-services heroku amazon-s3 nestjs


    【解决方案1】:

    同样的问题发生在我身上:

    1. 应用在本地运行良好
    2. 部署到 Heroku(爱好 dyno - 512Mb RAM)时,它会因 OOM 问题而崩溃

    基本上,您在启动时遇到的问题是,您的应用程序将使用比运行时更多的内存。在我的情况下,我必须删除一个 npm 包,以便它能够通过启动。

    据我所知,您有以下几种选择之一:

    • 设置heroku只安装prod dependencies - heroku config:set NPM_CONFIG_PRODUCTION=true
    • 尝试减少 3rd 方包依赖项的数量
    • 获得具有更大内存余量的测功机
    • 也许尝试将您的应用程序 docker 化并将图像部署到 heroku - 在 docker build 步骤中,您可以进行一些优化,例如npm dedupe - 但我不确定这是否真的有帮助

    【讨论】:

      猜你喜欢
      • 2020-03-30
      • 1970-01-01
      • 2013-12-05
      • 1970-01-01
      • 1970-01-01
      • 2015-05-11
      • 2019-09-14
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多