Nutanixストレージ視点からのPostgresのベンチマーク

  • 13 April 2022
  • 0 replies
  • 118 views

Userlevel 3

本記事は2019628日にGary Little氏が投稿した記事の翻訳版です。 

原文はこちら 

 

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

 

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

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

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

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

 

図:Prometheus/Grafanaによる、LinuxゲストVMの視点から見たIOレートのチャート

 

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

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

 

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

 

表:バースト時の長いキュー長にもかかわらずデータファイルへの書き込みを平均1.5ミリ秒で完了

 

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

 

表:データベースのデータファイルへの書き込みはほとんどランダム

 

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

 

表:書き込みのバーストは想定どおりoplogに渡る

 

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

 

表:一方、ログファイルへの書き込みは、ほとんどがシーケンシャルに分類される

 

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

 

表:これらの低同期ログ書き込みはoplog書き込みパターンに相当する

 


This topic has been closed for comments