こんにちは！
Docker で Discourse を運用しているのですが、RAM が不足してもスワップが一切使われず、再起動を数時間おきにしないとクラッシュしたり、ビルド時に「fatal error: out of memory allocating heap arena map」というエラーが出たりしてしまいます。
この問題を解決する方法をご存知でしょうか？
よろしくお願いいたします、
Kian
Linuxをお使いの場合、free -hコマンドは何を表示しますか？（できれば、再起動直後と、エラーが発生する直前の両方で確認してください。）
「いいね！」 2
swappiness が 0 に設定されている可能性がありますか？
cat /proc/sys/vm/swappiness
「いいね！」 2
こんにちは！
以前は40でしたが、現在は60に設定しました。
システムは常に RAM の大きなチャンクをキャッシュし、RAM の使用率が高くてもスワップは使用されません。
出力で注目すべきは、利用可能なメモリが 5.5GB、使用済みスワップが 0B、あるいは空きスワップが 9GB という部分でしょう。5.5GB と 9GB を足した値が、どれだけの余裕があるかを示しています。バッファとキャッシュに使用されるメモリ量は動的に変化するため、不足を引き起こすことはありません。
故障までの時間がわずか数時間しかない場合、vmstat 5 を実行して最終的な瞬間まで確認できるように出力をキャプチャすることをお勧めします。以前は、10 分ごとに vmstat 5 5 をログファイルに出力する cron ジョブを使用していました。
不具合のあるソフトウェアの場合、利用可能なリソースをあっという間に使い尽くす可能性があります。その場合、重要な瞬間にいくつかのスナップショットを取得できるよう、数分ごとに ps uax のログを取得すると非常に役立ちます。
また、他の制限が影響している可能性もあります。これは、何も実行されておらず特別な設定もない、クリーンな OS 上のクリーンなインストールでしょうか？
「いいね！」 2
こんにちは！
vmstat 5 を10分ごとにログに記録するにはどうすればよいでしょうか？また、ps uax を数分ごとにログに記録するにはどうすればよいでしょうか？
はい、これはバニラの Ubuntu Server 18.04 インストールです。Apache や Docker などの基本的なソフトウェアのみが入っています。
Varnish Cache がインストールされていることを思い出しました。これがキャッシュされた RAM を説明しています。しかし、Discourse がスワップも使用しない理由がわかりません。数日前に docker コマンドでスワップ制限を設定しましたが、何も変化がありませんでした。
cron を使うのがより良い方法ですが、ここでは安価で簡潔なワンライナーをご紹介します。
sh -c 'rm -f /tmp/stop; while [ ! -e /tmp/stop ]; do (date; uptime; free; ps faux; vmstat 5 5) >> /var/log/monitor.log; sleep 600; done' &
これは無限に実行され続けます。停止するには touch /tmp/stop を実行してください。
ログは /var/log/monitor.log に作成されます。最終的な出力を確認するには tail -99 を、ページ単位で閲覧するには less を使用してください。問題の発生を示すログのセクションを何らかの方法で見つける必要があります。
ここでは間違った質問をしているように感じられます。仮想メモリの管理、バッファの使用やスワップの使用を含め、それを担っているのは Linux カーネルです。free コマンドでスワップが設定されていると報告されるなら、それは正常な状態であり、あなたが何もしなくて構いません。
あなたの本当の問いは、「なぜ Discourse がうまく動作しないのか」「なぜ再起動が必要なのか」「なぜ fatal error が表示されるのか」という点です。
このトピックのタイトルを以下のように変更することを強くお勧めします。
Why “fatal error: out of memory allocating heap arena map”?
また、あなたがいくつかの異なる事象を観察しているように見えることが気になります。
- Discourse がたまにクラッシュする
- リビルド時にたまに「fatal error:… heap arena map」が表示される
- 数時間ごとにサーバーを再起動する必要がある
これら各観察事象がどのように関連しているのか、私には明確ではありません。
- Discourse がクラッシュしたと判断する根拠は何ですか？具体的にどのような事象を確認しましたか？
- リビルド時に必ず「fatal error:」が表示されますか？
- なぜリビルドを実行しているのですか？
- 再起動を促すきっかけは何ですか？また、サーバーの再起動をおっしゃっているのでしょうか？
これらの回答をお聞かせいただければ幸いです！
「いいね！」 1
ふむ、具体的に何を試されましたか？
docker stats --no-stream --no-trunc
を実行した際、MEM USAGE / LIMIT と MEM % はどのように表示されましたか？
（私の場合、LIMIT はマシンの物理メモリよりわずかに少ない値に設定されています。これは、コンテナ内で実行されているプロセスがスワップを引き起こす可能性が低いことを意味するかもしれません。そのため、スワップがほとんど、あるいは全く使用されていない状況でも、メモリ割り当てに失敗するプロセスが発生する可能性があります。）
こんにちは！
Discourse がクラッシュしたと思われます。ドメインにアクセスすると Nginx の 502 Bad Gateway エラーが表示されます。ただし、Docker コンテナは起動したままです。
はい、稀なケースを除いてそうです。
502 Bad Gateway が一時的に解決することが多いため、再構築しました。
サーバーを再起動してエラーが解消するか確認することもありますが、多くの場合、解決せず、再構築することで一時的に直ることが多いです。
エラーログもすぐにお送りします。
/var/log/monitor.log を実行しようとして tail -99 を使用すると、-bash: /var/log/monitor.log: 権限がありませんというエラーが表示されます。
（スクリーンショットから、“app” という名前のコンテナのメモリ制限が 7.8G で、使用率がわずか 3% であることが確認できます。これは問題ありません。追記：ただし、CPU 使用率が 100% に達している点は疑わしいかもしれません。）
このログファイルの末尾を確認する必要があるため、
tail -199 /var/log/monitor.log
を実行すれば必要な情報が得られるかもしれません。しかし、より多くの内容を確認する必要がある可能性もあります。ログファイルを zip 圧縮して添付するか、他の方法で共有していただけませんか？ログファイルのサイズはどれくらいですか？
ls -l /var/log/monitor.log
100% は 1 コアだと思います。システムは正常に動作しているからです。
log.txt|添付ファイル (25.0 KB)
ログの199行分。
monitor.txt (39.3 KB)
これが完全なログです 
ありがとうございます。すべて正常に見えますが、これは単一のスナップショットに過ぎません。本来であれば、10 分ごとにログに新しいセクションが追加されるはずです。Discourse で問題が発生するのを待ち、その後、直近の数セクションを共有してください。
正直なところ、何が起きているのか分かりません。
3 つの Unicorn プロセスが CPU を大量に消費していることに気づきますが、なぜそうなるのか理由が分かりません。
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME
COMMAND
x 434 51.9 2.8 443732 234144 ? Sl 18:26 0:11 \\_ unicorn master -E production -c config/unicorn.conf.rb
x 662 103 3.6 8877408 301148 ? Rl 18:26 0:08 | \\_ discourse sidekiq
x 686 99.7 3.6 8873312 301916 ? Rl 18:26 0:06 | \\_ unicorn worker[0] -E production -c config/unicorn.conf.rb
x 731 94.3 3.6 8873312 294368 ? Rl 18:26 0:05 | \\_ unicorn worker[1] -E production -c config/unicorn.conf.rb
x 744 77.2 3.3 8873312 276788 ? Rl 18:26 0:03 | \\_ unicorn worker[2] -E production -c config/unicorn.conf.rb
top を実行し、shift+m を押して RAM 使用量でソートすると、どのプロセスが最も RAM を消費しているか確認できます。その結果をここに投稿してください。
