アップグレード中にマシン全体がフリーズ

インストール
1

AIプラグインを試して（その後削除した）以来、/admin/upgrade の実行中にマシンが完全にハングするようになりました。

毎回ではありませんが、約80％の確率で発生します。

通常、EC2インスタンス全体がフリーズし、AWS EC2 Web UIから強制的に再起動する必要があります。

本日もフリーズしました。驚いたことに、完全にフリーズするわけではありません。ルートURLを開くと、次のように表示されます。

おっと

このディスカッションフォーラムを支えるソフトウェアで予期せぬ問題が発生しました。ご迷惑をおかけして申し訳ありません。

エラーに関する詳細情報は記録され、自動通知が生成されました。確認いたします。

追加のアクションは必要ありません。ただし、エラー状態が続く場合は、サイトのフィードバックカテゴリにディスカッションを投稿して、エラーを再現する手順を含め、追加の詳細を提供することができます。

再度再起動し、これまで修正してきた通常の sudo ./launcher rebuild app を実行してみます。今日もうまくいくことを祈っています。

私の質問

ログファイルなどを確認できる場所があれば教えていただけますか？少なくとも、ハングが発生する理由のエラーメッセージだけでも確認したいです。

2

公式のAIプラグインですか？

コンソールから実行して、どこでスタックするか確認し、ログを共有してください。

「いいね！」 1
3

はい、公式プラグインです。

app.yml からプラグインを再度削除し、再構築することでアンインストールしました。これだけでは不十分でしょうか？

「これ」とは何のことですか？ sudo ./launcher rebuild app のことですか？

「いいね！」 1
4

サーバーのスペックは？

オンラインアップグレードには、最近では最低でも4GBのサーバーと2GBのスワップが必要だと個人的には思います。

「いいね！」 2
5

AWS EC2「t2.medium」（vCPU x2、RAM 4GiB）を使用しています。

HDDは100GiBで、空き容量は60GiBです。

必要であれば、「t2.medium」をより大きなインスタンスタイプにアップグレードすることも可能です。

このセットアップが、公式AIプラグインのテストを行うまで（長年）問題なく動作していたのに、プラグインを削除した後になってからアップグレード中にハングが発生する理由が分かりません。

「いいね！」 1
6

もう一つ変更された点があります。それは、アップグレード先のソフトウェアのバージョンです。最近、より多くのメモリを必要とするようになりました。そのため、どちらか一方、あるいは両方が原因である可能性があると考えています。

一時的かつ元に戻せる方法として、より多くのRAMを搭載したインスタンスにアップグレードすることが、メモリ不足が問題であるかどうかをテストする最も簡単な方法でしょう。ただし、数回の再起動が必要になります。もう一つの方法は、スワップを追加することです。これも元に戻すことができます。

「いいね！」 3
7

スワップを追加してみます。

「いいね！」 2
8

ありがとう、みんな。これをどうやるかググってからやるよ :slight_smile:。

アップデート 1

スワップを 8 GiB 追加しました：

$ free -h
               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       290Mi       2.9Gi       1.0Mi       677Mi       3.3Gi
Swap:          8.0Gi          0B       8.0Gi

次のアップグレードの後、これが役立ったかどうか、ここにアップデートを投稿します。

アップデート 2

/admin/upgrade を実行し、RAM 使用量を監視しました：

$ free -h
               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       1.4Gi       1.5Gi        50Mi       891Mi       2.0Gi
Swap:          8.0Gi       200Mi       7.8Gi

そして、アップグレードは正常に完了しました。:tada: このまま維持できればと思います。

アップデート 3

数日後、そして何度かのアップグレードの後、ハングアップは二度と経験しませんでした。

したがって、スワップが解決策だったと思います。この問題で助けてくれたすべての人に改めて感謝します。

「いいね！」 2
9

これは少しトピックから外れますが、本当に理解したいです。2 GB の空き RAM があったのに、なぜ 200 MB を使用したスワップが役立ったのでしょうか？

（インチの世界では、SI 単位系は 10 のスケールを使用するため混乱しやすいことは理解していますが、なぜ Mi なのでしょうか？ Gi はギガの短縮形であることはある程度理解できますが、メガは Me になるべきでしょうか？）

「いいね！」 1
10

MiはMibibytes、GiはGibibytesのことだと思います。

「いいね！」 1
11

ありがとうございます。知りませんでした、当然ですね。でも、メビバイトですよ :wink:

そして、まだ知らなかった他の皆さんのために :smirking_face:

「いいね！」 2
12

元の問題は、おそらくメモリ不足のためにプロセスが終了したこと（OOM killerに注意）だと思います。スワップを追加したことで、メモリが枯渇しなくなりました。それらの2つのfreeの出力は、マシンのストレスが最も高い瞬間に非常に注意深く取得されたものでない限り、全体像を伝えていない可能性があります。興味深いのはピーク時のスワップ使用量だと思います。

しかし、MKJ’s Opinionated Discourse Deployment Configurationで言及されているカーネルチューナブルの問題もあります。これは正しく設定していますが、多くの人が正しく設定していない可能性があります。

メモリのオーバーコミットはRedisとはほとんど関係がないことに注意してください。Redisが正しく設定するようにヒントを与えてくれるのは親切なだけです。

「いいね！」 3
13

また /admin/upgrade を開始し、1 秒ごとに手動で tree -h を呼び出すためにシェルを開きました。

見つかった最も高いメモリ使用量の値は次のとおりです。

$ free -h
              total        used        free      shared  buff/cache   available
Mem:           3.8Gi       3.2Gi       120Mi        80Mi       542Mi       266Mi
Swap:          8.0Gi       276Mi       7.7Gi

アップグレードは成功しました。

「いいね！」 1
14

ビルド時には 4 GB はぎりぎりですが、最後のスクリーンショットが最も負荷の高い瞬間だと仮定した場合です。

そして、これも理解できないもう一つの点です。なぜ他の人はメモリ不足になるのに、私は多くのプラグインやコンポーネントを使用しているのに、問題が全く発生しなかったのか :thinking: 何がその違いを生むのでしょうか？

そして、過去形を使ったのは、現在 AI のために 8 GB になったからです（そして私にとっては価格差はそれほど重要ではありませんでしたが、それはまた別の話です）。

このスレッドはどこかに移動すべきでしょうか、それともスワップの使用が役立った理由としてこれを見ているのでしょうか？

とにかく。他の初心者にとって、低メモリとそれが発生する理由について少し語られている例をもう一つ紹介します。

これは、アップグレードが失敗した場合の FAQ の質問として強く挙げられます。しかし、その理由はほとんど説明されていません。

「いいね！」 1
15

@Jagster @uwe_keim これらのコマンドの出力を報告していただけますか

cat /proc/sys/vm/overcommit_memory 
cat /sys/kernel/mm/transparent_hugepage/enabled

私のシステムでは以下のようになっています

# cat /proc/sys/vm/overcommit_memory 
1
# cat /sys/kernel/mm/transparent_hugepage/enabled 
always madvise [never]
「いいね！」 1
16 
$ cat /proc/sys/vm/overcommit_memory
0

および

$ cat /sys/kernel/mm/transparent_hugepage/enabled
always [madvise] never
「いいね！」 1
17

@uwe_keim さん、ありがとうございます。スワップを追加する必要があったのは、カーネルのチューナブルが原因だと推測します。たとえそれが使用されていなかったとしても。(RAMを大量に追加する必要があった場合も同様です。利用可能な総メモリはRAM+スワップであるため。)

「いいね！」 1
18

サーバー設定は、推奨があればいつでも変更できます。

19 
root@foorumi-hel:/var/discourse# cat /proc/sys/vm/overcommit_memory
0
root@foorumi-hel:/var/discourse# cat /sys/kernel/mm/transparent_hugepage/enabled
always [madvise] never
「いいね！」 2
20

お勧めします！

これにより、将来の再起動が修正されます（現在の状態を確認せずにファイルを上書きすることに注意してください）：

echo 'sys.kernel.mm.transparent_hugepage.enabled=never' > /etc/sysctl.d/10-huge-pages.conf
echo 'vm.overcommit_memory=1' > /etc/sysctl.d/90-vm_overcommit_memory.conf
sysctl --system
「いいね！」 1