l3tnun / EPGStation

Mirakurun を使用した録画管理ソフト
https://twitter.com/l3tnun
MIT License
547 stars 148 forks source link

npm run build がswapを十分に用意してもheap limitしてしまう #669

Closed T-SUGIUE closed 4 months ago

T-SUGIUE commented 7 months ago

環境

Issue

下記の通りビルドしようとしたところ Reached heap limit Allocation failed - JavaScript heap out of memoryでビルド失敗してしまいます。 swapは拡張していて、node の heap についても最大サイズを指定はしています。 OSについては amrbian 23.2 でも Ubuntu 20.04 LTSでも同じ挙動をしていることを確認済みです。 回避策等ありますでしょうか?

root@orangepipc2:~/EPGStation# echo $NODE_OPTIONS
 --max-old-space-size=2048
root@orangepipc2:~/EPGStation# free -h
              total        used        free      shared  buff/cache   available
Mem:          987Mi       238Mi       624Mi       0.0Ki       125Mi       674Mi
Swap:         2.0Gi       118Mi       1.9Gi

root@orangepipc2:~/EPGStation# sysctl -a | grep swappiness
vm.swappiness = 100
root@orangepipc2:~/EPGStation# npm run build

> epgstation@2.7.3 build
> npm run build-server && npm run build-client

> epgstation@2.7.3 build-server
> npm run lint && npm run format && npm run compile

> epgstation@2.7.3 lint
> eslint --fix --ext .ts src/

> epgstation@2.7.3 format
> prettier --check --write 'src/**/*.ts'

Checking formatting...
All matched files use Prettier code style!

> epgstation@2.7.3 compile
> tsc

> epgstation@2.7.3 build-client
> cd client && npm run build

> epgstation-client@2.7.3 build
> NODE_OPTIONS='--openssl-legacy-provider' vue-cli-service build

?  Building for production...Starting type checking service...
Using 1 worker with 2048MB memory limit
?  Building for production...Browserslist: caniuse-lite is outdated. Please run:
npx browserslist@latest --update-db

Why you should do it regularly:
https://github.com/browserslist/browserslist#browsers-data-updating
?  Building for production...
<--- Last few GCs --->

[9023:0xfa95870]   342694 ms: Scavenge 481.9 (500.2) -> 481.8 (501.0) MB, 20.1 / 0.0 ms  (average mu = 0.415, current mu = 0.224) allocation failure;
[9023:0xfa95870]   342738 ms: Scavenge 482.8 (501.0) -> 482.7 (505.7) MB, 31.3 / 0.0 ms  (average mu = 0.415, current mu = 0.224) allocation failure;
[9023:0xfa95870]   345193 ms: Mark-sweep 488.5 (508.7) -> 486.0 (510.2) MB, 2409.6 / 0.0 ms  (average mu = 0.266, current mu = 0.060) allocation failure; scavenge might not succeed

<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
 1: 0xb7f974 node::Abort() [node]
 2: 0xa97f08  [node]
 3: 0xd40e78 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [node]
 4: 0xd41048 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [node]
 5: 0xf1f5fc  [node]
 6: 0xf31594 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
 7: 0xf0d718 v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
 8: 0xf0e6f0 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
 9: 0xef1380 v8::internal::Factory::NewFillerObject(int, v8::internal::AllocationAlignment, v8::internal::AllocationType, v8::internal::AllocationOrigin) [node]
10: 0x1297a34 v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [node]
11: 0x167c4ec  [node]
Aborted
T-SUGIUE commented 6 months ago

環境

上記に変更の上、python-is-python3をインストールの上で ようやくセットアップできました。 nodeをv18対応した際に導入したパッケージもしくはv18との相性問題な気がします。

l3tnun commented 4 months ago

なぜdockerを使用しないのでしょうか? ビルドがそもそも不要になります。

clientがメモリ不足となっている原因担っていますが、clientについてはどの環境でビルドしても何も変わりませんので、 別環境でclientをビルドもしくはdocker imageの中からclient/distを取り出して、設置するればよろしいかと思います。

いくらでも回避可能な問題ですのでクローズします。

T-SUGIUE commented 4 months ago

Dockerを使えるようなリッチなリソースばかりではないとも主張したいですが、 クロスコンパイルしろというならそれも一手ですのでそこはいいとして、

node v18対応() した後以降 JavaScript heap out of memory が出る問題は解決していないのではないですか?

l3tnun commented 4 months ago

Dockerを使えるようなリッチなリソースばかりではないとも主張したいですが、

EPGStationを動かすような環境であれば十分リッチだと思いますよ? 組み込み製品でも使用されていますし、特別な理由がなければdockerの利用を推奨します。

node v18対応() した後以降 JavaScript heap out of memory が出る問題は解決していないのではないですか?

node v18以前の環境でも発生しています。#225 がおそらく同じ問題だと思いますが、client のビルド時にメモリをそれなりに使うという話だけですので、特に対応予定はありません。