本記事は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倍)ことがわかります。
![](https://uploads-us-west-2.insided.com/nutanix-us/attachment/42511894-46f3-43a3-8057-7c713c38d13b.png)
データベースのフラッシュ(ディスクへの強制書き出し)がバースト的に発生し、それなりの(書き込みの)並立性があるにもかかわらず、Nutanix CVMは平均1.5ms*の書き込み応答時間を実現しています。
*1ms以下の書き込みが49%、2msから5ms以下の書き込みが41%
Nutanix CVMポート2009のハンドラから、個々のvdisk統計にアクセスすることができます。この場合、(以下の各図の見出しにある)vDisk 45269番はデータファイル用のディスクで、vDisk 40043番はデータベーストランザクションログ用のディスクにあたります。
![](https://uploads-us-west-2.insided.com/nutanix-us/attachment/91b95a16-e146-462a-b7b9-ba07226f33d8.png)
Nutanixのvdisk categorizerは、データベースデータファイルへの書き込みパターンをランダム性の高い書き込みと正しく識別しています。
![](https://uploads-us-west-2.insided.com/nutanix-us/attachment/2bf5bf82-e052-4d60-83ba-8327e3ecf551.png)
その結果、書き込みはoplogに渡されます。
![](https://uploads-us-west-2.insided.com/nutanix-us/attachment/22a80b0f-c5be-426d-99ce-aef3c748020c.png)
一方、ログの書き込みは、ほとんどがシーケンシャルに分類され、これはデータベースのログファイルのワークロードとして想定どおりです。
![](https://uploads-us-west-2.insided.com/nutanix-us/attachment/f61d0b90-f1ce-4ef2-afac-c2bb22d53910.png)
ログへの書き込みの多くはシーケンシャルとはいえ、同期性が低くサイズも小さい(16K~32Kサイズが多く見受けられる)。そのため、このログの書き込みの一部はoplogに渡るようなパターンとして扱われることもあります。
![](https://uploads-us-west-2.insided.com/nutanix-us/attachment/ef64b760-2acc-4212-a1c9-be8a09667096.png)