こんにちは。並河(@namikawa)です。
新型コロナウイルスが終息していくことを祈り、弊社もリモートワーク体制に移行しておりまして、私自身もほぼ自宅で過ごしている日々です。弊社では、従前よりフルリモートワークを遂行しているメンバーが数名いますので、各人のリモートワークへの移行も割とすんなり出来たのではないかと感じています。(細かい課題意識はもちろんありますが)
さて、閑話休題。
このブログでも散々話題に出ているかと思うのですが、弊社では技術や投資にまつわるデータを大量に保有しておりまして、それぞれのデータの特性や用途によって、データストアを使い分けています。
その中でも、RDB には PostgreSQL が以前より活用されていまして、今日のエントリの趣旨は、この PostgreSQL の基礎ベンチマーク数値をバージョン毎に差異があるかを確認してみた記録となります。
ベンチマークの取得環境について
ベンチマークを取得した環境について記載しておきます。
- ベンチマークに使用したソフトウェアは "pgbench" です。
- "pgbench" は PostgreSQL のソフトウェアに標準で同梱されているツール。
- 対象の PostgreSQL のバージョンは、 9.5, 9.6, 10, 11, 12 です。
- PostgreSQL を稼働させたサーバは、Google Compute Engine (GCE) の下記2インスタンスです。
- n1-standard-1 (1vCPU, 3.75GB)
- n1-standard-4 (4vCPU, 15GB)
- サーバで稼働させた OS は Ubuntu 20.04 LTS です。
- PostgreSQLのデータを置いたディスクは、SSD で容量は 100GB となります。ファイルシステムは ext4 です。
PostgreSQL の設定については、下記の2パターンを用意して試してみました。
- デフォルトの設定 (インストール時の状態)
- PGTune で生成した設定
環境のセットアップ
GCE でインスタンスを起動させて、以下のコマンドで PostgrSQL が稼働する環境を作ります。
# apt-get install curl ca-certificates gnupg # curl https://www.postgresql.org/media/keys/ACCC4CF8.asc | apt-key add - # sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list' # apt-get update # apt-get install postgresql-${バージョン番号}
これで、PostgreSQL サービスが稼働しているのと、pgbench も実行できる状態になっているはずです。
続いて、ベンチマークで使うデータセットを pgbench を使って実行します。
# su - postgres $ createdb test $ pgbench -i -s 10 test
pgbench コマンドは "-i" オプションが初期化モード、 "-s" オプションが生成されるデータの桁数を示します。デフォルトは 1 で、1 だと10万行となります。↑の例だと100万レコードでデータセットが生成された感じです。
ベンチマークの取得
次に、実際にベンチマークを取得してみます。 今回は、以下のコマンドで取得を行いました。
$ pgbench -c 16 -t 1000 test
"-c" はクライアント数なので、↑の例だと同時に 16 コネクションで同時実行していることになります。 "-t" オプションは、各クライアントが実行するトランザクション数です。
ベンチマークは、下記のそれぞれの条件において、上記のコマンドを5回実行し、その中央値を結果として記載しています。
ベンチマーク結果
今回とったベンチマークの結果が以下の表となります。
縦軸が PostgreSQL のバージョン。横軸の項目は、1つ目の表記がサーバのコア数で、2つ目の表記が PostgreSQL の設定です。で、結果の数値は TPS (excluding connections establishing) となります。
横軸の補足説明ですが、例えば、1つ目の "1core, default" だと、1コアのインスタンスで、デフォルトの PostgreSQL の設定を使った結果となります。4つ目の "4core, PGTune" は、4コアのインスタンスで、PostgreSQL の設定をPGTuneの推奨値に書き換えた結果となります。
グラフにすると以下。
こちらの結果から、概ね、バージョンを上げていくことで、TPSレベルでの基本的なパフォーマンスは伸びていっているように思います。またデフォルトの設定ではなく、PGTune の推奨値を使った方が、よりパフォーマンスが上がる結果になりました。
シングルコアのサーバ(今時あまり使わないかもしれませんが)だと、その結果は顕著です。
一方で、4コアのサーバを使った結果は、バージョンごとにさほど大きな差はつきませんでした。ひょっとしたらデータセットのサイズ、メモリサイズとその割り当て量が影響しているのかなとも思いますが、I/Oの状況等、あまり細かく見れていないので、もう少しレコード数を増やした検証も、後日行ってみたいなと考えています。
とりあえず、この数値だけみていると、バージョン 12 には上げていきたいなーと思ったので、「PostgreSQL の バグ修正状況を調べてみた。」を参考に、下半期以降とかでアップグレードしていきたいな、と思ったのでした。
・・・と、若干中途半端感は否めないのですが、今日はこの辺で。 本当は、もうちょいコア数をスケールさせたらどうなる?とか、データセットのサイズ変えたらどうなる?とか、クライアントのコネクション数やトランザクション数変えたらどうなる?とか、時間があれば色々やってみたいと思うので、また追試したら、結果報告したいと思いますー!
それでは!=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́
(@namikawa が書いた過去記事)
- 社内無線LAN環境改善のためにやったこと (2019/Summer)
- Linuxでユーザアカウントを無効化するエトセトラ
- /etc/hosts で同じホスト名に違うIPアドレスを設定したらどうなるか
- 何気に便利に使えるかもしれない authorized_keys のオプション
- Linuxでinodeが枯渇した場合にどうやって調査するか
- アスタミューゼの開発組織と採用に関するQAアレコレ
- Linuxでディスクキャッシュとして使える「bcache」を試してみた
- Google Compute Engine のディスク(SSD)ベンチマークを取ってみた
- nginx + ngx_mruby でSSL証明書の動的読み込みを実現して、作業がとても楽になった話
- クラウドにあるステージング環境のシステムコスト大幅削減を進めている話
- 企業向けエンジニアブログの作り方