ニフクラ ブログ

ニフクラ/FJ Cloud-Vやクラウドの技術について、エンジニアが語るブログです。

高速ディスクはどれぐらい速いのか?

日本仮想化技術の宮原です(@tmiyahar)。

今回から、ニフティクラウドの様々な機能を検証し、ブログで発信していきます。 皆さんの素朴な疑問に答えられるような内容にしていきたいと思っておりますので、ご期待ください。

さて、今回は「高速ディスクはどれぐらい速いのか?」というテーマです。 サーバーの種類ならば、CPU数やメモリ量などで性能が変わってくるのは分かりますが、ストレージの性能は明確な性能指標がないため、比較が難しいポイントの一つです。

そこで今回はデータベースの性能を測定することで、標準ディスクと比べて高速ディスクがどれぐらい速いのかを調べてみました。

pgbenchを使ってPostgreSQLの性能を測定

性能測定には、いつもストレージ性能の測定に使っている「pgbench」を使いました。

pgbenchはPostgreSQLのデータベース性能を調べることができるベンチマークソフトです。 Linux上で簡単に動かすことができるので、皆さんにもお勧めしたいベンチマークソフトの1つです。

特に、その他のストレージ性能を測定するベンチマークソフトに比べて、データベースという具体的なソフトウエアを使った性能測定になっている点が、よりリアルなシステム環境に近いという点で気に入っています。

pgbenchはTPC-Bというデータベースの標準的なベンチマークを参考に作られています。 設定次第でデータベースの検索のみ、検索更新の両方を測定でき、今回はストレージ性能を測定するので後者の検索更新で測定を行います。

もし、CPUやメモリの性能を測定したい場合には、前者の検索のみの機能を使うと良いでしょう。

ベンチマーク環境の構築

ベンチマーク環境に使用したゾーン、サーバーは以下の通りです。

ゾーンeast-14
タイプwlarge32(8vCPU・32GB)
OSCentOS 6.6 64bit Plain(CentOS 64bit)
DBPostgreSQL 9.4

サーバー起動後、以下の作業を行って、PostgreSQL 9.4が動作する環境を構築しました。 最新版のPostgreSQLをインストールするために、PostgreSQL RPM Building ProjectのRPMリポジトリを使用しています。

PostgreSQL RPM Building Project - Repository Packages
http://yum.postgresql.org/repopackages.php
  1. yum updateの実行
    # yum check-update
    # yum update
  2. PostgreSQL RPM Building ProjectからPostgreSQL 9.4を64ビット版CentOS 6にインストールするためのRepository Packagesをインストール
    # rpm -ivh http://yum.postgresql.org/9.4/redhat/rhel-6-x86_64/pgdg-centos94-9.4-1.noarch.rpm
  3. 必要なパッケージをインストール
    # yum install postgresql94-server postgresql94-contrib
  4. 高速ディスクを作成してサーバーに接続 screenshot_224
  5. 接続したディスクを認識させる
    # for i in $(find /sys/class/scsi_host -name 'scan') $(find /sys/devices -name 'scan') ;do echo "- - -" > $i ; done
  6. 認識されたディスクにパーティションを作成
    # fdisk /dev/sdb
  7. ext4ファイルシステムで初期化
    # mkfs -t ext4 /dev/sdb1
  8. 区別しやすくするためにラベルを付けておきます
    # e2label /dev/sdb1 HSD
  9. 同様に、比較用の標準ディスクも作成し、サーバーに接続後、ext4ファイルシステムで初期化します。
    # for i in $(find /sys/class/scsi_host -name 'scan') $(find /sys/devices -name 'scan') ;do echo "- - -" > $i ; done
    # fdisk /dev/sdc
    # mkfs -t ext4 /dev/sdc1
    # e2label /dev/sdc1 SD
  10. マウントポイントを作成します
    # mkdir /mnt/HSD
    # mkdir /mnt/SD
  11. 各ディスクをマウントします
    # mount LABEL=HSD /mnt/HSD
    # mount LABEL=SD /mnt/SD
  12. PostgreSQLのデータ領域として使うディレクトリを作成し、所有権、パーミッションを変更しておきます。
    # mkdir /mnt/HSD/data
    # chown postgres.postgres /mnt/HSD/data
    # chmod 700 /mnt/HSD/data
    # mkdir /mnt/SD/data
    # chown postgres.postgres /mnt/SD/data
    # chmod 700 /mnt/SD/data
  13. PostgreSQLのデータ領域用にシンボリックリンクを作成します。
    # ln -s /mnt/HSD/data /var/lib/pgsql/9.4/data.HSD
    # ln -s /mnt/SD/data /var/lib/pgsql/9.4/data.SD

以上で下準備は完了です。 実際にPostgreSQLを動作させて、ベンチマークを行います。

標準ディスクをベンチマーク

まず、標準ディスク環境でPostgreSQLを初期化します。

# mv /var/lib/pgsql/9.4/data.SD /var/lib/pgsql/9.4/data
# /etc/init.d/postgresql-9.4 initdb
# /etc/init.d/postgresql-9.4 start

ベンチマークはユーザーpostgresで動作させます。 また、インストールしたPostgreSQLのバイナリにパスを通して置く必要がありますので、.bash_profileを変更しておきます。

# su - postgres
$ vi .bash_profile
PATH=$PATH:/usr/pgsql-9.4/bin/

$ source .bash_profile

pgbenchデータベースを作成します。

$ createdb pgbench

pgbenchコマンドに-iオプションをつけて実行し、初期データベースを構築します。

-sオプションでスケールファクタ(DBサイズ)を指定します。 スケールファクタ1あたり10万件の初期データが作成されます。

ここではスケール20を設定しています。

$ pgbench -i -s 20 pgbench

pgbenchコマンドを実行してベンチマークを行います。

-cオプションでクライアント数を指定しますが、初期データベースで指定したスケールファクタと同じ程度を指定してみます。

また、ベンチマーク時間はあまり短いと結果がぶれることがあるので、300秒ベンチマークを実行します。

$ pgbench -c 20 -T 300 pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 20
query mode: simple
number of clients: 20
number of threads: 1
duration: 300 s
number of transactions actually processed: 348401
latency average: 17.222 ms
tps = 1159.802499 (including connections establishing)
tps = 1160.153345 (excluding connections establishing)

結果1160tpsの性能であることが分かります。

高速ディスクをベンチマーク

次に高速ディスクをベンチマークします。

PostgreSQLを停止後、データベースの格納領域を切り替えておきます。

# /etc/init.d/postgresql-9.4 stop
# mv /var/lib/pgsql/9.4/data /var/lib/pgsql/9.4/data.SD
# mv /var/lib/pgsql/9.4/data.HSD /var/lib/pgsql/9.4/data
# /etc/init.d/postgresql-9.4 initdb
# /etc/init.d/postgresql-9.4 start

pgbench用の初期データベースを作成します。

$ createdb pgbench
$ pgbench -i -s 20 pgbench

pgbenchを同じ条件で実行します。

$ pgbench -c 20 -T 300 pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 20
query mode: simple
number of clients: 20
number of threads: 1
duration: 300 s
number of transactions actually processed: 464783
latency average: 12.909 ms
tps = 1549.094302 (including connections establishing)
tps = 1549.489277 (excluding connections establishing)

今度は1549tpsという結果が出ました。

標準ディスクが1160tpsですから、およそ33%ほど高速ということになりますが、思ったよりも性能が出ていないと思うかもしれません。

スケールファクタ20_tps

原因を推測するに、十分なサイズのデータベースでないと、様々なバッファキャッシュの効果が働いて標準ディスクでも性能が出る場合があります。

そこで、大きなpgbench用の初期データベースを作成してベンチマークを比較してみます。

スケールファクタ1000での比較

十分に大きいデータベースにするために、スケールファクタを1000(1億件)のデータベースを作成します。

$ dropdb pgbench
$ createdb pgbench

大きいデータベースを作成するには時間がかかるので、作成時間も比較してみます。

標準ディスクでの作成時間

$ pgbench -i -s 1000 pgbench
100000000 of 100000000 tuples (100%) done (elapsed 203.96 s, remaining 0.00 s).

高速ディスクでの作成時間

$ pgbench -i -s 1000 pgbench
100000000 of 100000000 tuples (100%) done (elapsed 109.54 s, remaining 0.00 s).

作成時間で約2倍ほどの性能差が確認できます。

また、標準ディスクの方は作成の途中で数秒停止してしまうことがあり、ストレージ側にボトルネックが発生していることが分かりました。

スケールファクタ1000_作成時間

標準ディスクのベンチマーク結果

$ pgbench -c 20 -T 300 pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1000
query mode: simple
number of clients: 20
number of threads: 1
duration: 300 s
number of transactions actually processed: 103086
latency average: 58.204 ms
tps = 343.552139 (including connections establishing)
tps = 343.719059 (excluding connections establishing)

高速ディスクのベンチマーク結果

$ pgbench -c 20 -T 300 pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1000
query mode: simple
number of clients: 20
number of threads: 1
duration: 300 s
number of transactions actually processed: 414925
latency average: 14.460 ms
tps = 1382.852263 (including connections establishing)
tps = 1383.195432 (excluding connections establishing)

標準ディスクが343tpsに対して、高速ディスクが1383tpsと4倍の性能差が出ているのが分かります。

スケールファクタ1000_tps

また、注目したいのはレイテンシ(応答速度)で、高速ディスクはスケールファクタが20の時と大きく変わらないレイテンシであるのに対して、標準ディスクは大幅にレイテンシが劣化している、すなわちストレージにボトルネックが発生して性能が低下しているのが分かります。

データベースのサイズが大きくなると、バッファキャッシュにデータが収まりきらなくなるため、ストレージの性能がデータベースの性能に直接影響するようになります。

データサイズが大きくなることが分かっているのであれば、最初から高速ディスクを選択するべきですし、もしシステムの運用中に性能が劣化しているように感じられたら、データベースのサイズを確認し、必要に応じて高速ディスクへの移行を検討してみてください。

注:本計測はあくまで筆者の環境を使った計測時点での値であり、計測環境、計測時間によって異なる可能性が大です。あくまで参考程度に留めておいてください。