ClickHouse Managed Postgres、Huge Pagesで共有メモリ性能を安定化

ClickHouseは管理対象Postgresで2MB Huge Pagesを確実に使うため、メモリの25%を起動前に予約し、通常ページへの代替を許さず、実測した共有メモリ追加負荷を差し引く設計を説明しました。

要点

• 4KBページでは100GBキャッシュと100接続でページテーブルだけに約20GB必要になる計算です。
• huge_pages = 'on'とし、予約不足なら起動失敗させて暗黙の代替を防ぎます。
• r7i.4xlargeの検証では200接続時のPageTablesが6.12GBから111MBになり、pgbenchによる読み取り専用ベンチマークは12%向上しました。

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

OSは通常4KB単位でメモリを管理し、CPUは仮想アドレスから物理アドレスへの変換をTLBへ保持します。2MB Huge Pagesは一つの項目で512倍の範囲を扱えるため、大きなshared_buffersを全バックエンドプロセスが割り当てするPostgresで効果が大きくなります。記事の例では100GBキャッシュを4KBページで扱うと1接続当たり約200MBのページテーブルが必要ですが、2MBなら数十MB規模に抑えられます。

管理対象Postgresはホストメモリの25%をHuge Pagesとして、Postgres起動前に予約します。キャッシュを解放してメモリを集約し、連続する2MBページを確保します。HugePages_Totalが不足すれば準備を失敗させます。稼働後に断片化したホストでは同じ予約が失敗しやすいためです。Postgres側は既定のtryではなくhuge_pages = 'on'を設定します。tryでは4KBページへ静かに切り替わり、性能劣化に気付けない可能性があるからです。実行環境でもPostgreSQLの親プロセスについて、/proc/<pid>/statusにあるHugetlbPagesを確認します。

予約量はshared_buffersだけでは決まりません。バッファ記述子、WALバッファ、ロックテーブルを含む共有メモリ区画は、32GBのshared_buffersに対して例では32.75GBでした。まず全プールを指定し、postgres -D -C shared_memory_sizeで実区画を測り、差分をshared_buffersから引いて8KB単位へ丸めます。128GB、16 vCPUのEC2で15.6GBデータセットをキャッシュし、200接続で測ると4KBはPageTablesが6.12GB、2MB Huge Pagesは111MBでした。100 clientのpgbenchは373,083 TPSから418,087 TPSへ向上しています。単なる調整項目ではなく、予約、早期失敗、実測容量設計を一体にする運用設計です。

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

大規模Postgresを運用するSRE、データベース管理者、管理対象サービス設計者、接続数とメモリ追加負荷を調査する性能エンジニアに関係します。

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

12%のスループット向上という数値より、接続数に比例するページテーブルの負担を構造的に減らす点が重要です。自前環境へ適用する場合は、OS、コンテナ、クラウドインスタンスのHuge Pages制約、再起動時の予約、監視、メモリの過剰割り当てを同時に検証する必要があります。