DB_shared_buffers（総RAMの0.1%）とDB_work_mem（総RAMの0.03%）を増やせません

markersocial · 2024 年 11 月 29 日午後 10:02

これは少し頭を悩ませる問題ですね

新サーバーに新しく移行した Discourse インスタンスがあります。

ログで以下のエラーが発生しています: PG::DiskFull (ERROR: could not resize shared memory segment \"/PostgreSQL.1759815625\" to 8388608 bytes: No space left on device )

これは奇妙です。なぜなら、以前のサーバー（RAM 64GB）ではこの問題はなく、以下の設定を使用していました:

db_shared_buffers: "25632MB"
db_work_mem: "160MB"

新しいサーバー（RAM 128GB）では、デフォルト値以上に増やすことができません（以下の値を3倍にしても、同じ PG DiskFull エラーが発生します）:

db_shared_buffers: "128MB"
db_work_mem: "40MB"

以前のマシンには Docker 27.x がインストールされていました（Discourse インストーラーによって自動インストールされました）。新しいマシンには、指示に従って docker.io をインストールしました（そのため 26.x です）。関連性があるか確認するために Docker 27.x に切り替えてみましたが、何も変わりませんでした。どちらも Stable Discourse ブランチ、バージョン 3.3.2 です。

shm_size が主な原因のようです:

しかし、以前のサーバーでは問題なかったのに、新しいサーバーで問題になっている理由がわかりません。唯一の大きな違いは、古いサーバーが Ubuntu 22.04 LTS を使用しており、新しいサーバーが 24.04 LTS であることです。

これも試しましたが、コンテナが再起動されると変更が上書きされてしまいます。

shm_size はランチャーにハードコードされているようです:

github.com/discourse/discourse_docker

launcher

40169e876


      
               if [ -z "$SKIP_MAC_ADDRESS" ] ; then
                mac_address="--mac-address $($docker_path run $user_args -i --rm -a stdout -a stderr $image /bin/sh -c "echo $hostname | md5sum | sed 's/^\(..\)\(..\)\(..\)\(..\)\(..\).*$/02:\1:\2:\3:\4:\5/'")"
               fi
          
               if [ ! -z "$START_CMD_ONLY" ] ; then
                 docker_path="true"
               fi
          
               set -x
          
               $docker_path run --shm-size=512m $links $attach_on_run $restart_policy "${env[@]}" "${labels[@]}" -h "$hostname" \
                  -e DOCKER_HOST_IP="$docker_ip" --name $config -t "${ports[@]}" $volumes $mac_address $user_args \
                  $run_image $boot_command
          
             )
             exit 0
          
          }
          
          run_run() {
            set_template_info

github.com/discourse/discourse_docker

launcher

40169e876


      
          
          }
          
          run_run() {
            set_template_info
            set_volumes
            set_links
            set_run_image
          
            unset ERR
            (exec $docker_path run --rm --shm-size=512m $user_args $links "${env[@]}" -e DOCKER_HOST_IP="$docker_ip" -i -a stdin -a stdout -a stderr $volumes $run_image \
              /bin/bash -c "$run_command") || ERR=$?
          
            if [[ $ERR > 0 ]]; then
              exit 1
            fi
          }
          
          run_bootstrap() {
            # Is the image available?
            # If not, pull it here so the user is aware what's happening.

github.com/discourse/discourse_docker

launcher

40169e876


      
          fi
          run_command="$run_command /pups/bin/pups --stdin"
          
          echo $run_command
          
          unset ERR
          
          tmp_input_file=$(mktemp)
          
          echo "$input" > "$tmp_input_file"
          (exec cat "$tmp_input_file" | $docker_path run --shm-size=512m $user_args $links "${env[@]}" -e DOCKER_HOST_IP="$docker_ip" --cidfile $cidbootstrap -i -a stdin -a stdout -a stderr $volumes $image \
            /bin/bash -c "$run_command") || ERR=$?
          
          rm -f "$tmp_input_file"
          
          unset FAILED
          # magic exit code that indicates a retry
          if [[ "$ERR" == 77 ]]; then
            $docker_path rm `cat $cidbootstrap`
            rm $cidbootstrap
            exit 77

何か洞察や助けがあれば幸いです！

pfaffman · 2024 年 11 月 29 日午後 10:51

RAMではなく、ハードドライブの空き容量を指します。

markersocial · 2024 年 11 月 29 日午後 11:40

@pfaffman ありがとうございます。私も最初はそう思いましたが、このスレッドを読みました。

空き容量もたくさんあるのに

markersocial · 2024 年 11 月 30 日午前 3:30

簡単なダクトテープでの修正方法は、ランチャーファイルを編集するだけです。

cd /var/discourse
vi launcher

次に、--shm-size=512m の3つの出現箇所をすべて、希望するRAM量（私はシステムRAMの50％を使用しました）に置き換えます。

その後、再構築します。ランチャーが更新されるたびに、再度編集する必要があります。

とりあえず、これでうまくいっているようです。

water leaking fix with flex tape

markersocial · 2024 年 12 月 5 日午前 8:10

Michael K Johnson:

カーネル設定

Redis（Discourseが構築されている主要コンポーネントの1つ）は、ディスク永続化を使用する場合に透過的な巨大ページを無効にすることを強く推奨しています（Discourseはこれを行います）。また、メモリのオーバーコミットも許可しています。
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

したがって、他の誰かがこの問題に直面した場合に備えてフォローアップします。上記で問題が解決しました。ランチャーでshm-sizeを編集する必要はなくなりました。

これは、再構築中にこの警告に気づいた後に見つかりました。
WARNING メモリのオーバーコミットを有効にする必要があります！無効にすると、メモリ不足の状態でバックグラウンド保存またはレプリケーションが失敗する可能性があります。無効にすると、メモリ不足の状態でも失敗する可能性があり、https://github.com/jemalloc/jemalloc/issues/1328 を参照してください。この問題を修正するには、/etc/sysctl.conf に 'vm.overcommit_memory = 1' を追加してから再起動するか、このコマンドを実行して 'sysctl vm.overcommit_memory=1' を有効にしてください。

トピック		返信	表示
PG throws could not resize shared memory segment error Installation	6	26978	2024 年 6 月 8 日
What process fills the disk every 2 hours? Hosting	2	86	2025 年 7 月 19 日
Setup fails: Cannot allocate memory Installation	3	2185	2022 年 8 月 4 日
Discourse Bad Gateway after reboot Installation	16	2084	2020 年 8 月 1 日
Docker shm_size Option in app.yml Feature	10	1507	2024 年 11 月 29 日

DB_shared_buffers（総RAMの0.1%）とDB_work_mem（総RAMの0.03%）を増やせません

関連トピック