zoul
2024 年 1 月 10 日午前 10:13
1
Digital Ocean のドロップレットでイメージを再構築していますが、時間がかかっているものがあります。
I, [2024-01-10T09:47:14.854311 #1] INFO -- : cd /var/www/discourse & su discourse -c 'bundle exec rake themes:update assets:precompile'
Node.js heap_size_limit (492.75) is less than 2048MB. Setting --max-old-space-size=2048.
[WARN] (broccoli-terser-sourcemap) Minifying "assets/admin.js" took: 25461ms (more than 20,000ms)
[WARN] (broccoli-terser-sourcemap) Minifying "assets/plugins/chat.js" took: 47818ms (more than 20,000ms)
Purging temp files
Bundling assets
I, [2024-01-10T10:06:07.644096 #3264] INFO -- : Writing /var/www/discourse/public/assets/break_string-cc617154cd957804f2f6a1f3bc68258c9cdca3d4b9a322bf777d145fed04790e.js
ドロップレットは 1 GB の RAM を搭載しており、それ以外は Discourse を問題なく実行しています。何か間違っていますか？再構築を高速化するために何かできますか？よろしくお願いします！
「いいね！」 1
これでメモリが非常に制限されると思います。
Discourseインスタンスには最低4GB（スワップも含む！）を推奨するようになりつつあります（2GB + 2GBのスワップでもオンラインアップデートが非常に遅いと感じます）。
「いいね！」 3
zoul
2024 年 1 月 10 日午前 10:33
3
ありがとうございます！残念ながら、それはアップデート中にしか感じられないであろう改善に対して、価格が4倍になってしまいます。また、クラウドインストールガイドには次のように書かれています。
デフォルトの1 GB RAMは、小規模なDiscourseコミュニティで問題なく動作します。大規模なコミュニティには2 GB RAMをお勧めします。
このステップでのメモリプレッシャーの原因はわかりますか？おそらく、圧縮率を下げるなどして、メモリ要件を減らすことは可能でしょうか？
RGJ
2024 年 1 月 10 日午前 11:44
4
Ember CLI から来ています。
すでに時間と空間のトレードオフ（メモリ不足によりプロセスに時間がかかる）を経験しています。
「いいね！」 3
Ed_S
2024 年 1 月 10 日午後 1:19
6
私の2つのサーバーでの次のアップデートでは、ホスティングプロバイダーの柔軟性を利用して、アップデート前にRAMを増やし、その後すぐに現在の最小構成に戻すつもりです。ダウンタイムはわずかに増えますが、再構築が大幅に速くなるのであれば、全体としてプラスになる可能性があります。追加費用は1ドル未満、あるいは1セント程度で済むでしょう。RAMの追加（私の場合は月額6ドルから月額12ドルへ、Digital Oceanではそれぞれ1セントと2セントで時間単位で課金されます）は1時間あたりです。
リンクされたスレッドで指摘されているように、再起動が役立つ場合もあるため、OSパッケージを更新して再起動するのは良いタイミングです。
これにより、私自身の負担も軽減されることを願っています。
実際には、スワップファイルを一時的に削除したり、ディスク容量の不足を緩和したりできるように、1Gから8Gに増やすことを選択するかもしれません。その場合、1時間あたり追加で6セントかかります。
すべてがアップデート時にピークに達します。それ以外の時間は、現在の最小構成で十分なようです。
アップグレードサイクルごとに6セントを支払う余裕は十分にあります。
「いいね！」 4
それは素晴らしいですね！ホスティングプロバイダーはどこですか？
Ed_S
2024 年 1 月 10 日午後 1:27
8
Robert:
あなたのホスティングプロバイダーはどこですか？
一方（1G RAM）はDigital Ocean、もう一方（2G RAM）はHetznerです。
どちらもRAMを一時的にオンラインでインプレースで増やすことができますか？
それとも「ドロップレット」/インスタンス間を移動する必要がありますか？
それとも再起動だけですか？
RGJ
2024 年 1 月 10 日午後 1:33
10
いいえ、
Ed S:
わずかな追加のダウンタイムがあります
シャットダウン - リサイズ - 起動 - 再構築 - シャットダウン - リサイズバック - 起動です
「いいね！」 4
OK、でもまだインプレースですね。それは素晴らしいオプションですが、確かに余計な手間がかかりますし、ダウンタイムもあります。
1GBのマシンの再構築に時間がかかることを考えると、どうせ30分はダウンするので、これを行っても構わないでしょう！
そして確かに、もしあなたがそれを行う準備ができているなら、一時的に16GBのマシンにアップグレードすることもコスト的には問題ないかもしれません
多くの人は自分の時間をより価値のあるものだと考え、恒久的に4GB以上に移行することを考え始めるべきだと思います。
「いいね！」 1
Ed_S
2024 年 1 月 10 日午後 1:40
12
それは確かにコストと時間のトレードオフの一部です。私自身は、アップグレードのために1時間のベビーシッターをすることにすでにコミットしており、このシステム管理のダンスを完全にどのように行うかを知っているので、時間はすでに予約されています。月々のランニングコストは、時間がかかっても、できるだけ低く抑えたいと思っています。他の人は他のトレードオフを持つでしょう。
確かに、お金を簡単に使うことができるなら、快適に大きなインスタンスを手に入れましょう！
「いいね！」 1
Ed_S
2024 年 1 月 10 日午後 4:35
13
参考までに、私のフォーラム2つを更新しましたが、どちらも1時間以内に完了しました。どちらの場合も、一時的にRAMを8GBに拡大してから元に戻しました。この特定の手順には、(一時的に)CPU4個とRAM8GBで約5分かかりました。
I, [2024-01-10T16:07:58.323464 #1] INFO -- : cd /var/www/discourse && su discourse -c 'bundle exec rake themes:update assets:precompile'
110:M 10 Jan 2024 16:08:52.047 * 100 changes in 300 seconds. Saving...
110:M 10 Jan 2024 16:08:52.048 * Background saving started by pid 3276
3276:C 10 Jan 2024 16:08:52.384 * DB saved on disk
3276:C 10 Jan 2024 16:08:52.386 * Fork CoW for RDB: current 1 MB, peak 1 MB, average 0 MB
110:M 10 Jan 2024 16:08:52.449 * Background saving terminated with success
Purging temp files
Bundling assets
MaxMind IP database updates require a license
Please set DISCOURSE_MAXMIND_LICENSE_KEY to one you generated at https://www.maxmind.com
MaxMind IP database updates require a license
Please set DISCOURSE_MAXMIND_LICENSE_KEY to one you generated at https://www.maxmind.com
I, [2024-01-10T16:12:14.362017 #3300] INFO -- : Writing /var/www/discourse/public/assets/break_string-cc617154cd957804f2f6a1f3bc68258c9cdca3d4b9a322bf777d145fed04790e.js
ここでは、ember（12列目）が2.5GのRAM（6列目）を使用しており、CPUを1つ以上使用している（3列目）ことがわかります。
# ps auxfc|egrep -A29 containerd
root 1097 0.2 0.5 1510892 44924 ? Ssl 16:00 0:01 containerd
root 4507 0.1 0.0 717892 7556 ? Sl 16:03 0:00 \_ containerd-shim
root 4530 0.1 0.3 312292 30512 ? Ssl 16:03 0:00 \_ pups
systemd+ 4609 0.0 0.3 213236 28608 ? S 16:03 0:00 \_ postmaster
systemd+ 4617 0.0 0.8 213340 67288 ? Ss 16:03 0:00 | \_ postmaster
systemd+ 4618 0.0 0.0 213236 5876 ? Ss 16:03 0:00 | \_ postmaster
systemd+ 4619 0.0 0.1 213236 10076 ? Ss 16:03 0:00 | \_ postmaster
systemd+ 4620 0.0 0.1 213904 8860 ? Ss 16:03 0:00 | \_ postmaster
systemd+ 4621 0.0 0.0 68004 5592 ? Ss 16:03 0:00 | \_ postmaster
systemd+ 4622 0.0 0.0 213796 7100 ? Ss 16:03 0:00 | \_ postmaster
message+ 4682 0.2 0.4 87976 35724 ? Sl 16:03 0:00 \_ redis-server
1000 7722 1.1 0.0 0 0 ? Z 16:07 0:01 \_ esbuild <defunct>
root 7736 0.0 0.0 2476 520 ? S 16:07 0:00 \_ sh
root 7737 0.0 0.0 9296 4156 ? S 16:07 0:00 | \_ su
1000 7738 8.3 0.0 2476 580 ? Ss 16:07 0:12 | \_ sh
1000 7835 0.4 0.9 929524 78416 ? Sl 16:08 0:00 | \_ node
1000 7857 0.0 0.0 2484 524 ? S 16:08 0:00 | \_ sh
1000 7858 156 30.5 67413228 2491796 ? Sl 16:08 3:37 | \_ ember
1000 7876 39.0 1.7 11486300 145476 ? Ssl 16:08 0:44 | \_ node
1000 7882 36.7 1.5 11466956 122648 ? Ssl 16:08 0:41 | \_ node
1000 7889 37.1 4.1 11647592 340908 ? Ssl 16:08 0:42 | \_ node
1000 7761 1.5 0.0 0 0 ? Z 16:08 0:02 \_ esbuild <defunct>
おそらくRAM 4GBで十分だったでしょうが、前述の通り、この一連の作業全体で数セントしかかかりませんでした。（より高速なCPUを選択すれば、さらに1セント追加で済んだことが今わかりました。）
編集：作業を開始する前にバックアップを取り、完了後に再度バックアップを取りました。それらの間隔は35分でした。したがって、ユーザーから見たダウンタイムはそれ以上ではありませんでした。
編集：Digital Oceanのコントロールパネルでは、リサイズ操作はディスク上のデータ1GBあたり最大1分かかる場合があると表示されています。私の場合はデータは14GBのみで、実際にはリサイズごとに2分しかかかりませんでした。しかし、インスタンスに大量のデータがある場合、このリサイズ操作はさらに時間がかかる可能性があります。（また、大量のデータがある場合は、おそらく4GB未満のRAMで実行しようとはしないでしょう。）
「いいね！」 3
Ed S:
おそらく4GBのRAMで十分だったでしょう
4GBのRAMでも、場合によっては十分ではありません。例えば、トラフィックはほとんどないものの、5つの使い捨てサンドボックスを保持できるようにマルチサイト設定になっている8GBのRAMサンドボックスがあります。昨日、エラー137（OOM）により再構築が失敗し、@richardさんが上記で提案したトリックを試しました 。しかし、毎回この手間を省くために、より大きなスワップ（4GB）を作成したところ、今のところ再構築が可能になりました。ディスコースの再構築が何らかの理由で非常にRAMを消費するようになっているため、過去1年間でサーバーをアップグレードしているだけのようです。
「いいね！」 2
Ed_S
2024 年 1 月 10 日午後 5:29
15
興味深いですね。MKJ’s Opinionated Discourse Deployment Configuration に記載されているようなカーネル設定はありますか？
（スワップは、2Gまたは4G、あるいは利用可能なディスク容量に応じて、常に用意しておく価値があります。私のディスク容量は最小限なので、スワップも最小限です。）
merefield
2024 年 1 月 11 日午前 11:05
16
これを考えると、メリットはフルリビルドに限定されます。2+2構成ではオンラインアップグレードを使用できません
個人的には、少なくとも4GBへの永続的なアップグレードが唯一の方法だと思います…
注：時代の流れに乗らなければならないことについて不平を言っているわけではありません…しかし、ドキュメントや管理者へのアドバイスに現実を反映させ始めるべきではないでしょうか？
残念ながら、これによりDiscourseは新規、特に若い人々にとって少しアクセスしにくくなりますね
「いいね！」 1
Ed_S
2024 年 1 月 11 日午後 12:41
17
このアイデアには私も賛成です。現在の最小推奨構成をターゲットとして維持し、コードの調整やアップストリームの変更を検討して、状況を抑制します。最小構成の価格が2倍になるのは、提供内容における大きな変更です。だからこそ、私は他の場所で、過剰なメモリ要件はバグであると述べました。
「いいね！」 2
zoul
2024 年 1 月 31 日午後 1:48
18
最新バージョンへのアップグレードを試みると、アップグレードが失敗するようになりました。
...[@embroider/webpack]
Killed
error Command failed with exit code 137.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
Docker Manager: FAILED TO UPGRADE
#<RuntimeError: RuntimeError>
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:210:in `run'
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:111:in `upgrade'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:19:in `block in <main>'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:6:in `fork'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:6:in `<main>'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/railties-7.0.5.1/lib/rails/commands/runner/runner_command.rb:43:in `load'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/railties-7.0.5.1/lib/rails/commands/runner/runner_command.rb:43:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/thor-1.2.2/lib/thor/command.rb:27:in `run'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/thor-1.2.2/lib/thor/invocation.rb:127:in `invoke_command'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/thor-1.2.2/lib/thor.rb:392:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/railties-7.0.5.1/lib/rails/command/base.rb:87:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/railties-7.0.5.1/lib/rails/command.rb:48:in `invoke'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/railties-7.0.5.1/lib/rails/commands.rb:18:in `<main>'
internal:/usr/local/lib/ruby/site_ruby/3.2.0/rubygems/core_ext/kernel_require.rb:37:in `require'
internal:/usr/local/lib/ruby/site_ruby/3.2.0/rubygems/core_ext/kernel_require.rb:37:in `require'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/bootsnap-1.16.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:32:in `require'
bin/rails:18:in `<main>'
Spinning up 1 Unicorn worker(s) that were stopped initially
これはメモリ不足のエラーでしょうか？ 1GBのマシンは公式にサポートされなくなったということでしょうか？
Ed_S
2024 年 1 月 31 日午後 2:07
19
はい、それはメモリ不足のエラーです。スワップを追加するディスク容量があれば十分ですが、RAMを追加する場合よりも時間がかかります。ホスティングプロバイダーは、一時的にRAMをアップグレードしてから元に戻すオプションを提供している場合があります。これには、おそらく数回の再起動、少しのダウンタイム、そして数セントの追加費用がかかるでしょう。
編集：明確にするために、メモリ = RAM + スワップです。RAMは高速で、スワップは安価です。
「いいね！」 2
…単一のプラグインなどをアップデートするために、このアップグレード/ダウングレードのダンスをするつもりはないと思います…