本文へジャンプします。

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

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

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

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

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

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

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

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

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

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

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

ベンチマーク環境の構築

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

ゾーン east-14
タイプ wlarge32(8vCPU・32GB)
OS CentOS 6.6 64bit Plain(CentOS 64bit)
DB PostgreSQL 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の時と大きく変わらないレイテンシであるのに対して、標準ディスクは大幅にレイテンシが劣化している、すなわちストレージにボトルネックが発生して性能が低下しているのが分かります。

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

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

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

ニフティクラウド 導入相談窓口
ニフティクラウド 無料セミナー

閉じる

閉じる

クラウドブログ編集部

クラウドブログ編集部

ニフティクラウド ユーザーブログ編集部のアカウントです。 編集部からのお知らせや、レギュラーライター以外のゲストによる寄稿記事を掲載していきます。

浜中 慶

浜中 慶

1980年、神奈川県生まれ。2003年ニフティ入社。 ポータルサイト開発を中心に、音楽配信サービス、CGMサービスなど様々なプロジェクトに企画/デザイン/システム担当として参加。現在は@niftyのポータルサービス向けコンテンツ管理システムの企画/開発/運用を担当。

吉田 雄哉

吉田 雄哉

株式会社co-meetingの創業メンバー。「取締役&External- facing Technologist」と名乗り新しいIT技術を広く伝える活動とWebアプリケーション開発を行う毎日。パッケージベンダーでのSaaS立上げ・製造業の情報システム部門で企画やPM・受託開発と従事してきたため、ベンダーサイドとユーザサイド の両方の視点を持ち合わせる。

石田 健亮

石田 健亮

株式会社ドリーム・アーツで小売事業者向けSaaS「Shopらん」を企画、開発。メインの仕事はプログラマーだがサーバー管理や営業もこなすユーティリティプレイヤー。最近好きな事はパフォーマンスチューニング。特に並列化プログラミングがマイブーム。キライなことはデータセンターでの作業。騒音と乾燥が弱点。ニフティクラウドでデータセンターに行く必要が無くなったことが本当の利点だ と思っている。

五月女 雄一

五月女 雄一

ニフティでは「インフラを守る簡単な様で奥が深いお仕事」をしています。 夢はインフラの気持ちが読めるエンジニアになること。

わたなべ かずひろ

わたなべ かずひろ

専門学校卒業後、ソフトウェア開発会社で電力系統制御システムの開発に従事。その後、CD-ROM等マルチメディア系PCソフトの開発を経て、1998年フリーランスに。 2000年8月に株式会社イーツーの設立に参画。携帯を含む様々なWeb系のシステム開発に携わる。現在はiPhone/Androidアプリなどの開発も手がけている。

市角

市角

ニフティクラウドのコントロールパネル設計・開発をメインに、たまにインフラの運用やお手伝いもやっていたりします。コントロールパネルや新機能の活用方法、アイデアなどを中心に書いていく予定です。

仲山 昌宏

仲山 昌宏

歌って踊れるインフラエンジニア兼、PHPもRubyもJavaも書くPerl使い。 物理サーバの運用に飽きて、フルラックに格安サーバ詰めて自宅プライベートクラウドを構築中。 今年は個人的には分散処理を攻めていきます。

猪飼 賢広

猪飼 賢広

1984年、愛知県名古屋市生まれ。大学は福島県にある某大学。2008年ニフティに入社。 開発系部署に配属後、主に各種テーマサイト開発のシステム面調整、開発進行管理役などとして参加。 現在もPC・ガラケーサイトの開発まわりを担当。インフラまわりを触る案件にも携わっており、日々修行中。 好きな芸人はなかやまきんに君とレイザーラモンRG。

久江 裕之

久江 裕之

ニフティクラウドのインフラ運用、OS提供の仕事をしています。 新しいOSやイメージが出る時にこのブログでご紹介いたします。入社5年目。一流のインフラエンジニアを目指して日々勉強中。

竹内 豪

竹内 豪

ニフティクラウド エンジニア

山口

山口

ニフティクラウドの基盤設計、新サービス/アライアンス/インフラ企画、その他雑用全般を担当しています。 クラウドに欲しい機能や、こんなふうに使ってほしいという想いが共有できれば良いですね。

芳中 隆幸

芳中 隆幸

ニフティクラウドの開発、運用を担当しています。

酒井 浩平

酒井 浩平

ニフティクラウドの中にいます。 ネットワークまわりの運用・開発や自動化などに取り組んでいます。 すべてのエンジニアを幸せにすることを目指しています。

higebu

higebu

ニフティクラウド IaaSのエンジニアです。 ネットワーク、DRサービス with VMware vCloud® Air™ Technology辺りの担当をしています。

武田

武田

ニフティクラウドの開発・運用を担当しています。 各種機能の内容についてなどで執筆させていただく予定です。

福澤真

福澤真

ニフティクラウドのコンパネ開発、運用をしています。

森藤 大地

森藤 大地

データに関する仕事が好きです。

宮原徹

宮原徹

日本仮想化技術株式会社 代表取締役社長兼CEO。仮想化技術に関するコンサルタントとして長年活動しており、特にベンチマークテストによる性能評価を得意としている。

荒谷翔

荒谷翔

株式会社はてなでMackerelのセールスデベロッパーとして勤務しています

東條 望

東條 望

2014年にニフティへ中途入社。 入社後から現在まで、ニフティクラウドのサービス企画・開発を担当しています。 各サービスの紹介を執筆させていただく予定です。

世良迪夫

世良迪夫

ニフティクラウドのRDBなどを担当しています