私は単一ノードの proxmox クラスターを持っており、PostgreSQL と TimescaleDB で新しい VM を起動したいと考えています。この目的のために ZFS ボリュームを調整する方法について多くの資料を読みましたが、キャッシュ オプションについてはまだ疑問が残っています。キャッシュは 3 つあります。proxmox のキャッシュ (ARC)、Linux VM のキャッシュ (LRU)、PostgreSQL のキャッシュ (クロック スイープ) です。DB から遠いものから近いものへの順です。
私は多くの情報を読みました。矛盾しているものもあるので、これが本当かどうかはわかりませんが、PG キャッシュは、すべてをキャッチして、キャッシュを続行するのに十分なスペースがない場合にのみ削除しようとするカーネル キャッシュと同じようには設計されていないようです。実際、PG キャッシュは、現在処理中のデータ用のバッファのようなもので、長期キャッシュではありません。確かに、これは共有バッファと呼ばれます。ドキュメントでは、ARC のように shared_buffers を使用可能な RAM の 25% から 50% の間に設定することを推奨していないのはそのためだと思います。実際の PG キャッシュはカーネル キャッシュであり、shared_buffers ではないようです。
これを考慮すると、考慮すべきいくつかの構成があります。
- 適度な量の RAM (たとえば 12 GB) を持つ VM を作成し、shared_buffers を 10 GB に設定します。これを使用して、次の操作を試します。1) 進行中のクエリのバッファーとして機能する十分な量のメモリを用意します。2) VM RAM を抑制してキャッシュを使用しないようにします。LRU 構成ではキャッシュは最悪になるはずなので、代わりに重み付けが適切な ARC を使用します。この構成の問題は、キャッシュが VM の外部にあるため、パフォーマンスが向上するのではなく低下する可能性があることから発生する可能性があります。また、VM OS とその他の DB プロセスを実行するために、shared_buffers サイズにどれだけ余裕を残す必要があるかわかりません。
- 大容量の RAM (たとえば 48 GB) を搭載した VM を作成し、shared_buffers を同じ 10 GB 内に維持します。また、zfs はプライマリ キャッシュをメタデータに設定します。この方法では、キャッシュは DB に近くなり、VM 内になりますが、ロジックは最悪です。LRU は DB にはあまり適していないようです。
- 大量の RAM と primarycache=all を持つ VM を作成します。これは、次の理由で良くないと思います: 1) VM と proxmox キャッシュがリソースを競合します。2) キャッシュが重複します。
コンテキストを説明すると、ノードには合計 64 GB の RAM があり、PG/timescaleDB はそこで実行されるより要求の厳しい/優先度の高いアプリケーションになります。
それで、私の最初の仮定は正しいでしょうか? どの構成の方がうまく機能しますか? 何を変更しますか?
よろしくお願いいたします。お時間をいただきありがとうございました。
ヘクター
答え1
私の推奨は、ソリューション #4 を使用することです。大量の RAM を搭載した VM を作成し、KVM (Proxmox) 側でcache=noneデータ ディスクとして使用します。これにより、Proxmox はホスト ページ キャッシュをまったく使用しなくなり、実際のストレージ同期が効果的に実行されます。この方法では、VM を可能な限りベア メタルに近づけ、そこでキャッシュを微調整できます。
私が知っているすべてのデータベース (PostgreSQL を含む) では、RAM バッファは単なるディスク キャッシュではなく、少なくとも一部のデータをディスク上の形式ではなく読み取り可能な形式で保持します。これは、DB プロセス用に確保された RAM は、I/O バッファとしてのみ使用される RAM よりも価値があることを意味します。
DB が (独自の) RAM からクエリに応答できる場合、IO スタックをまったく経由しないため、レイテンシが大幅に削減されます。