本記事は2019年6月28日にGary Little氏が投稿した記事の翻訳版です。 

原文はこちら。 

前回のパート1とパート2の Postgres と pgbench の検証に続き、今回は、Postgres と pgbench の検証です。Nutanix CVMからワークロードがどのように見えるか、簡単に見ていきましょう。

Postgresを実行しているLinux VMには2つの仮想ディスクがあります：

• 1つはトランザクションログの書き込みを行っています。
• もう1つはメインデータファイルの読み込みと書き込みを行います。

データベースのサイズは小さいので（Linux RAMの50%のサイズ）、データはほとんどゲスト内部にキャッシュされており、ほとんどの読み出しはストレージにヒット（ストレージへのI/Oアクセス）しません。その結果、主にDB ファイルへの書き込みのみが表示されます。
 

さらに、データベースのデータファイルへの書き込みはバースト的にストレージへ到着し、これらの書き込みバーストはログファイルへの書き込みよりも激しい（〜10倍）ことがわかります。

データベースのフラッシュ（ディスクへの強制書き出し）がバースト的に発生し、それなりの（書き込みの）並立性があるにもかかわらず、Nutanix CVMは平均1.5ms*の書き込み応答時間を実現しています。

*1ms以下の書き込みが49%、2msから5ms以下の書き込みが41%

Nutanix CVMポート2009のハンドラから、個々のvdisk統計にアクセスすることができます。この場合、（以下の各図の見出しにある）vDisk 45269番はデータファイル用のディスクで、vDisk 40043番はデータベーストランザクションログ用のディスクにあたります。

Nutanixのvdisk categorizerは、データベースデータファイルへの書き込みパターンをランダム性の高い書き込みと正しく識別しています。

その結果、書き込みはoplogに渡されます。

一方、ログの書き込みは、ほとんどがシーケンシャルに分類され、これはデータベースのログファイルのワークロードとして想定どおりです。

ログへの書き込みの多くはシーケンシャルとはいえ、同期性が低くサイズも小さい（16K～32Kサイズが多く見受けられる）。そのため、このログの書き込みの一部はoplogに渡るようなパターンとして扱われることもあります。