andreid
2023 年 11 月 26 日午後 6:00
1
こんにちは。
3.2.0.beta3-dev から 3.2.0.beta3 へのアップグレードを促されて試したところ、アセットの ember build 中にメモリ不足が発生し、Discourse インスタンスが破損しました。./launcher rebuild app を試しましたが、結果は同じでした。
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
1: 0xb83f50 node::Abort() [ember]
2: 0xa94834 [ember]
3: 0xd647c0 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [ember]
4: 0xd64b67 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [ember]
5: 0xf42265 [ember]
6: 0xf5474d v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [ember]
7: 0xf2ee4e v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [ember]
8: 0xf30217 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [ember]
9: 0xf113ea v8::internal::Factory::NewFillerObject(int, v8::internal::AllocationAlignment, v8::internal::AllocationType, v8::internal::AllocationOrigin) [ember]
10: 0x12d674f v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [ember]
11: 0x17035b9 [ember]
Aborted (core dumped)
error Command failed with exit code 134.
I, [2023-11-26T17:19:26.345389 #1] INFO -- : yarn run v1.22.19
$ /var/www/discourse/app/assets/javascripts/node_modules/.bin/ember build
Environment: development
WARNING: ember-test-selectors: You are using an unsupported ember-cli-babel version. data-test properties are not automatically stripped from your JS code.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
非営利団体向けの DigitalOcean インスタンスで 1GB のメモリを使用しており、メモリを増やすためにスケールアップする余裕はありません。1GB は Discourse の最小サイズであり、以前のバージョンでは問題なく動作していました。再度動作させるためのアイデアはありますか？
andreid
2023 年 11 月 26 日午後 6:40
3
合計 使用量 空き 共有 バッファ/キャッシュ 利用可能
メモリ: 952Mi 321Mi 414Mi 3.1Mi 374Mi 631Mi
スワップ: 2.0Gi 75Mi 1.9Gi
Hetznerへの移行を検討することをお勧めします。Hetznerは、競争力のある価格と、ベースプランで2GBのRAMを提供しています。
「いいね！」 1
こんにちは、ようこそ @andreid
私の1GB DOテストサイトも最近、再構築中にメモリの問題に苦労していました。それを乗り越えるために一時的に2GBにアップグレードしました。
「いいね！」 1
ドキュメントの最小要件を2GB RAMに更新する価値があるかもしれませんね。
「いいね！」 2
andreid
2023 年 11 月 26 日午後 8:39
10
@RGJ 、@JammyDodger 、ありがとうございます。一時的にサイズを変更したところ、うまくいきました。
「いいね！」 3
Ed_S
2023 年 11 月 29 日午後 10:02
11
1Gのスワップを追加することは、ディスク容量があれば1GのRAMを追加することと機能的に同じになるはずです。（アップグレードの実行には時間がかかるかもしれませんが、それはパフォーマンスの問題であり、機能の問題ではありません。あなたが望むのは、メモリ不足の状況を回避することです。）
Discourse 側の問題軽減に役立つかもしれない追加情報があります。私のインスタンス（DigitalOcean の約 1GB ドロップレット、2GB スワップ付き）では、最近再構築に著しく時間がかかるようになり、4 回に 3 回の割合で同じ致命的なエラーが報告されています（./launcher cleanup を実行すると運が良くなるようですが、これを確定するにはサンプルサイズが不足しています）。
ヒープメモリ不足のエラーの直前に、次の行がログに記録されます。
Node.js heap_size_limit (491.0) is less than 1024MB. Setting --max-old-space-size=1024.
Node.js heap_size_limit (491.0) is less than 2048MB. Disabling Webpack parallelization with JOBS=0 to conserve memory.
私はこの分野の専門外なので、何か間違っていたら申し訳ありません。簡単な調査によると、ember-cli は node.js に依存しているため、これが関連していると考えています。--max-old-space-size フラグは、RAM よりも高く設定できる可能性があります（単にスワップスペースに入るだけで、前述のようにこの場合は問題ありません）。したがって、1024 は Discourse の再構築が収まらなくなった人工的な上限である可能性があります。
補足： apparently --optimize-for-size はメモリ使用量を削減するのに役立つ node.js フラグです（Discourse/ember によって使用されているかどうかはわかりませんが、おそらくすでに使用されています）、また、一部の node.js の使用ではガベージコレクタが有効になっていないという逸話があり、これは問題である可能性があります。
もしこれが ember/node.js の使用における Discourse 側から制御可能で関連性がある場合、誰かが調査する価値があるかもしれません。そうでなければ、心配しないでください。上記で提案されている一時的な 2GB アップグレードソリューションを実行します。
「いいね！」 1
david
2023 年 12 月 11 日午後 9:38
14
それは非常に良い点です！現在、低RAMのマシンでは1024MBに引き上げていますこちら 。1500または2000に増やすことを試して、それが役立つかどうかを確認することができます。
もしご自身で試す時間と意欲があれば、アプリのymlファイルのenv:セクションに新しい変数を追加することで設定できます。
編集：
NODE_OPTIONS: "--max-old-space-size=2048"
「いいね！」 3
Troid92
2023 年 12 月 11 日午後 10:04
15
ああ、完璧です！試してみました。
致命的なエラーは毎回発生するわけではなく、最近のリビルドには約25分（以前は5〜10分）かかるため、その数値を増やすことでこれらのサーバー仕様のメモリの問題が解決するかどうかを知るには時間がかかるかもしれません。
しかし、リビルドログに2つのNode.js heap_size_limitの警告が表示されなくなり、最初のリビルドが成功したことはすでに確認できます。これは有望です。
編集：アプリのapp.ymlの上記のNODE_OPTIONS設定のおかげで、問題なく数回リビルドできるようになりました。やった！
編集2：このソリューションは、他の低RAMマシンが引き続き動作できるように、そのマジックナンバー （Davidの投稿からのリンク）を増やすことで、Discourseに組み込まれるべきでしょう。もしこれを知っている人がこれを読んだら、それは素晴らしいことです。
「いいね！」 2
こちらも https://caddy.community で同様の問題が発生しました。
./launcher rebuild app を数回実行しましたが、さまざまな問題で失敗しました。bundle install が rbtrace に関して苦情を申し立て (An error occurred while installing rbtrace (0.5.0), and Bundler cannot continue. で終了)、問題が発生しました。
その後、この OOM 問題が発生しました。
I, [2023-12-12T07:50:59.497921 #1] INFO -- : > cd /var/www/discourse & su discourse -c 'bundle exec rake themes:update assets:precompile'
Node.js heap_size_limit (1010.0) is less than 1024MB. Setting --max-old-space-size=1024.
Node.js heap_size_limit (1010.0) is less than 2048MB. Disabling Webpack parallelization with JOBS=0 to conserve memory.
<--- Last few GCs --->
[3683:0x5dab130] 279104 ms: Scavenge 981.3 (1037.1) -> 974.5 (1037.1) MB, 8.3 / 0.0 ms (average mu = 0.699, current mu = 0.681) allocation failure;
[3683:0x5dab130] 279136 ms: Scavenge 981.8 (1037.1) -> 975.0 (1037.1) MB, 8.0 / 0.0 ms (average mu = 0.699, current mu = 0.681) allocation failure;
[3683:0x5dab130] 282606 ms: Mark-sweep 994.8 (1050.6) -> 987.7 (1048.9) MB, 3316.1 / 0.0 ms (average mu = 0.593, current mu = 0.501) allocation failure; GC in old space requested
<--- JS stacktrace --->
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
1: 0xb83f50 node::Abort() [ember]
2: 0xa94834 [ember]
3: 0xd647c0 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [ember]
4: 0xd64b67 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [ember]
5: 0xf42265 [ember]
6: 0xf5474d v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, [snip]
Aborted (core dumped)
error Command failed with exit code 134.
そして最終的に ./discourse_doctor で実行したところ、最終的にはそれを乗り越えることができました (なぜかは不明ですが、後続の実行でキャッシュが増え、メモリ使用量が少なくなったのでしょうか？
I, [2023-12-12T08:02:50.556442 #1] INFO -- : > cd /var/www/discourse & su discourse -c 'bundle exec rake themes:update assets:precompile'
Node.js heap_size_limit (1010.0) is less than 1024MB. Setting --max-old-space-size=1024.
Node.js heap_size_limit (1010.0) is less than 2048MB. Disabling Webpack parallelization with JOBS=0 to conserve memory.
110:M 12 Dec 2023 08:07:50.026 * 100 changes in 300 seconds. Saving...
110:M 12 Dec 2023 08:07:50.030 * Background saving started by pid 3706
3706:C 12 Dec 2023 08:07:51.292 * DB saved on disk
3706:C 12 Dec 2023 08:07:51.294 * Fork CoW for RDB: current 1 MB, peak 1 MB, average 1 MB
110:M 12 Dec 2023 08:07:51.334 * Background saving terminated with success
Purging temp files
Bundling assets
しかし、これは本来経験する必要のない摩擦でした。将来的には改善されることを願っています。
参考までに:
# free -h
total used free shared buff/cache available
Mem: 1.9Gi 1.3Gi 87Mi 138Mi 593Mi 394Mi
Swap: 2.0Gi 337Mi 1.7Gi
「いいね！」 1
Falco
2023 年 12 月 12 日午後 4:21
17
確かに、だからこそここで情報を収集しているのです。
NODE_OPTIONS環境変数を調整するだけでよいようです。したがって、アプリの依存関係またはV8の変更のいずれかによって、以前の値が機能しなくなったと推測されます。
@david これはどのように見えますか？
main ← low-ram-help
opened 04:20PM - 12 Dec 23 UTC
See https://meta.discourse.org/t/upgrade-from-3-2-0-beta3-dev-to-3-2-0-beta3-fai… led-due-to-out-of-memory/286643/14?u=falco
Co-authored-by: David Taylor <david@taylorhq.com>
「いいね！」 1
david
2023 年 12 月 12 日午後 5:06
18
これで良さそうです！明らかに 30 分以上の再構築はまだ理想的ではありませんので、近い将来に改善できることを願っています。しかし、これは損失を食い止めるための良い解決策のように思えます。
「いいね！」 2
volanar
2023 年 12 月 12 日午後 5:50
19
注目すべきは、PostgreSQL バージョン 16 がバージョン 13 と比較して、より少ないスペースを消費し、はるかに最適化されていることです。これにより、サーバーメモリの総消費量を削減できます。
nathank
2024 年 1 月 8 日午後 10:44
20
本日、小規模サイトで2GB+2GBスワップ設定の同様のリビルド問題が発生しました。
今回は2GB+4GBスワップに拡張することで、問題を乗り越えることができました。
「いいね！」 2
david
2024 年 2 月 5 日午後 1:17
21
tophee
2024 年 2 月 6 日午後 8:27
22
参考までに、私の場合は、app.yml に以下を追加しても役に立ちませんでした。
役に立ったのは、単に以下を実行することでした。
sudo apt update
sudo apt upgrade
「いいね！」 2
これは現在Discourseのデフォルトです。自分で設定する必要はありません。
)