コンテナがメモリ制限に達すると、高いシステム負荷

最近、GitLab docker / nomadコンテナが定義されたメモリ制限（10G）に達し、私のサーバーがクラッシュしました。制限に達すると、コンテナのCPU時間の100％がカーネルスペースで消費されます。 （コンテナは4つのCPUコアに制限されます。）最終的にホストがロックされ、SSH接続に応答しなくなります。

カーネルログにはOOM出口は表示されません。また、disk ioの急増を発見しましたが、説明することはできません。

既存のGitLabデータとNomadなしでより小さな例を作成しました。

config=$(cat <<'EOS'
external_url 'https://xxxxxxxxx'
nginx['listen_port'] = 80
nginx['listen_https'] = false
nginx['proxy_set_headers'] = {
 'Host' => '$http_host_with_default',
 'X-Real-IP' => '$remote_addr',
 'X-Forwarded-For' => '$proxy_add_x_forwarded_for',
 'X-Forwarded-Proto' => 'https',
 'X-Forwarded-Ssl' => 'on',
 'Upgrade' => '$http_upgrade',
 'Connection' => '$connection_upgrade'
}
EOS
)

# Started with
docker run --rm -d --memory="5G" \
    --name testgitlab \
    --publish 10.0.0.1:9001:80 \
    -e "GITLAB_SSL=true" \
    -e "GITLAB_OMNIBUS_CONFIG=$config" \
    gitlab/gitlab-ce:latest

同じことが起こりました。システムの負荷が100％に達するとすぐにコンテナを停止しました（今回はCPU制限なし）。

最初はこれがGitLabのバグだと思いましたが、私のラップトップでも同じことを試みましたが、メモリ制限に達すると、OOMキラーはすぐにコンテナプロセスを終了しました。この問題は、GitLabコンテナの実行に使用した以前のサーバーでも発生しませんでした。

この資料に記載されているすべてのシステムには特別なDocker設定がなく、スワップが無効になっており、ネットワークサブシステムのsysctl設定のみが変更されます。

• 前のサーバー：Debian 10
  • バスターバックポートのカーネル（5.10.0-0.bpo.9-amd64）
  • ファイルシステム：md-raid 1のbtrfs（2x nvme ssd）
• 現在のサーバー：Debian 11
  • ブルスアイカーネル(5.10.0-9-amd64)そしてブルズアイバックポート（5.14.0-0.bpo.2-amd64）カーネル。両方のコアに問題が発生します。
  • ファイルシステム：md-raid 1のlvmのbtrfs（2x nvme SSD）
• 私のラップトップ：アーチ
  • カーネル: 5.15.5-arch1-1
  • ファイルシステム：lvmのext4、ssdのnvme

GitLabがメモリ制限に達したときにホストがハングするのを防ぐ方法は？なぜ現在のサーバーにのみ影響しますか？

修正する：sonatype / nexusコンテナを使用してこの動作を再現できます。したがって、これはGitLabの問題ではありません。

アップデート2：ページキャッシュの欠落が急増していることがわかりました。おそらくこれ理由は何ですか、cgroupsですか？しかし、既存のサーバーやラップトップはなぜ影響を受けませんか？

アップデート3：mdraid1+lvm+btrfsを使用してVMを起動すると再現できます。さらなる調査...