ClickHouse Managed Postgresが厳格なメモリ過剰確約を採用

ClickHouseは、Managed Postgresで厳格なメモリ過剰確約を使う理由を、実験結果とともに説明しました。

要点

• Linuxの既定の過剰確約では、メモリ不足時にOOM killerがPostgresバックエンドをSIGKILLする可能性があります。
• PostgresではバックエンドのSIGKILLがインスタンス全体の再起動とWAL recoveryにつながり、無関係な接続も落ちます。
• 厳格なメモリ過剰確約では、割り当て時点でENOMEMを返し、問題のクエリだけを失敗させやすくなります。

今回のブログ記事で語られていること

今回のClickHouseブログは、ClickHouse Managed PostgresでLinuxのvm.overcommit_memory = 2を使う理由を説明しています。Linuxでは、プロセスがメモリを要求した時点で物理メモリをすぐ確保せず、実際にページが触られた時に割り当てる仕組みがあります。既定の過剰確約ポリシーでは、実際に支えられる以上のメモリ確約を許すことがあり、最後に物理メモリが尽きるとOOM killerがプロセスを強制終了します。

Postgresでは、この挙動の影響が特に大きくなります。Postgresのバックエンドは共有バッファ、WALバッファ、ロックテーブルを含む共有メモリセグメントを使います。あるバックエンドがSIGKILLされると、共有状態の整合性が保証できないため、postmasterは安全側に倒して全バックエンドを終了し、接続を落とし、WAL recoveryを行います。つまり、メモリを使いすぎた一つのクエリが、無関係な20の接続を巻き込むような障害につながります。

記事では、m7i.2xlarge、Postgres 16、shared_buffers、pgbenchデータセットを使い、既定ポリシーと厳格な過剰確約を比較しています。既定ポリシーでは、巨大な配列集計を行うセッションが増えた結果、OOM killerがバックエンドを落とし、20の待機セッションも切断され、約30秒の停止が発生しました。厳格な過剰確約では、確約上限を明示的に設定し、メモリ不足を物理メモリ枯渇前のout of memoryエラーとして返します。この場合、問題のクエリだけが失敗し、他のセッションや新規接続は維持されました。性能面では、読み取り専用と読み書きのベンチマークで、差は実行ばらつきの範囲に収まると説明されています。

今回のブログ記事が関係する人

Postgresを本番運用するDBA、ClickHouse Managed Postgresを評価するデータ基盤担当、メモリ不足時の障害範囲を小さくしたいSREに関係します。

結局、今回のブログ記事をどう読むべきか

これはPostgresのメモリ設定を、性能チューニングではなく障害封じ込めとして見る記事です。管理者は、OOM killを起こしてから復旧する設計ではなく、クエリ単位の失敗で止められる設定を検討したいです。