概要
前回の続き。ディスクサイズが50GB, 100GB, 200GB, 400GB, 600GBのパターンで、それぞれ負荷をかけてIO性能を観察する。
負荷のかけ方は、MySQLのLOAD DATA LOCAL INFILEで巨大なデータを読み込ませる。
結論
一つ一つの検証結果の前に、結論を書いておく。
- ディスクサイズを増やすと、IO性能はその増加率に近い割合で向上した
- ディスクサイズを２倍にすると、IO性能（IOPS, スループット）は約1.8倍になった
- ただし、一定以上はIO性能が伸びなくなったため、ボトルネックが別の箇所に移ったと思われる
- CPU、メモリ、NWのいずれも頭打ちになっている様子は見えないので、MySQL内部の可能性が高い
- ディスクサイズから計算されるIO性能と実際に出ている性能が一致しない
- 「実際に出ている性能」とは、Stackdriverのメトリクスから取得したもの。これを正しく理解できていない可能性もある
- ディスクサイズの選択は、必要なディスク領域によって決めがちだが、必要なIO性能という観点でも考えた方がいい
- SSDの場合、ストレージ料金は\$0.22/month。例えば、50GBから100GBにディスクサイズを増やしたとき、\$11/monthの追加コストでIO性能を倍にできる
環境（共通）
- CloudSQL
- MySQL 第 2 世代
- MySQL 5.7
- ストレージの種類:SSD
- クライアント
- ComputeEngine
- Debian GNU/Linux 9
- vCPU x 2、メモリ 7.5 GB
- 検証データ
- 31GB（CSVファイル）、43GB（MySQLテーブル）、31,017,889行
検証
table_load.shを実行した。
検証によっては、２つのプロセスからこのスクリプトを実行している。（テーブルは別のテーブルにロード）
パターン1
CloudSQLの設定が下記。スループットとIOPSは、ディスクサイズによって決まる最大の値。（GCPのWebUIから確認可能。CloudSQL->インスタンスを選択->編集->ディスクの設定のところ）
| vCPU | メモリ | ディスクサイズ | 読み取りスループット(MB/秒) | 書き込みスループット(MB/秒) | 読み取り IOPS | 書き込み IOPS |
|---|---|---|---|---|---|---|
| 2 | 7.5 GB | 50GB | 24.0 | 24.0 | 1500 | 1500 |
結果
Stackdriverのメトリクスから取得した結果をまとめる。
| 項目 | 値 |
|---|---|
| 所要時間 | １時間20分 |
| WriteOperations | 600/sで安定。終了直前だけ、862/sというスパイクが見られた。 |
| InnoDB pages written | 480/s前後で安定。終了直前だけ、770/sというスパイクが見られた。 |
| 書き込み量 | 7.5 MB/s(16384 * 480 / 1024 / 1024) innodb_page_sizeから推定。 |
| Network Bytes Received By MySQL | 6.3 MB/sで前後で安定 |
| CPU Utilization | 60%前後で安定 |
クライアント側
何かがボトルネックになっている様子はない。
パターン2
二つのプロセスからデータをロード。テーブル名はそれぞれ変える。
結果
ほぼパターン１と変わらず。念のためクライアントとMySQLのスケールをアップしたが、IO性能は変わらず。
パターン3
ディスクサイズを２倍に増やした。
| vCPU | メモリ | ディスクサイズ | 読み取りスループット(MB/秒) | 書き込みスループット(MB/秒) | 読み取り IOPS | 書き込み IOPS |
|---|---|---|---|---|---|---|
| 2 | 7.5 GB | 100GB | 48.0 | 48.0 | 3000 | 3000 |
結果
CloudSQL
| 項目 | 値 |
|---|---|
| WriteOperations | 1080/s前後で安定 |
| InnoDB pages written | 860/s前後で安定 |
| 書き込み量 | 13.4375 MB/s(16384 * 860 / 1024 / 1024) innodb_page_sizeから推定。 |
| Network Bytes Received By MySQL | 11 MB/s前後で安定 |
| CPU Utilization | 60%前後で安定 |
IOPS(WriteOperations)、スループット（１秒あたりの書き込み量）ともにディスクサイズを増やす前の1.8倍になった。
ディスクの増加率（２倍）と同じにはならなかったが、IO性能の向上が見られた。
パターン4
二つのプロセスから、異なるテーブルにデータをロードする。
結果
パターン3とIO関連のメトリクスについては変わらず。CPU使用率が少し増え約65%。
パターン5
ディスクサイズを２倍に増やした。
| vCPU | メモリ | ディスクサイズ | 読み取りスループット(MB/秒) | 書き込みスループット(MB/秒) | 読み取り IOPS | 書き込み IOPS |
|---|---|---|---|---|---|---|
| 2 | 7.5 GB | 200GB | 96.0 | 96.0 | 6000 | 6000 |
結果
| 項目 | 値 |
|---|---|
| WriteOperations | 2000/s前後で安定 |
| InnoDB pages written | 1600/s前後で安定 |
| 書き込み量 | 25 MB/s(16384 * 1600 / 1024 / 1024) innodb_page_sizeから推定。 |
| Network Bytes Received By MySQL | 21 MB/s前後で安定 |
| CPU Utilization | 60%前後で安定 |
IOPS(WriteOperations)、スループット（１秒あたりの書き込み量）ともに約1.85倍になった。
パターン6
ディスクサイズを２倍に増やした。
| vCPU | メモリ | ディスクサイズ | 読み取りスループット(MB/秒) | 書き込みスループット(MB/秒) | 読み取り IOPS | 書き込み IOPS |
|---|---|---|---|---|---|---|
| 2 | 7.5 GB | 400GB | 192.0 | 151.5 | 12,000 | 12,000 |
結果
| 項目 | 値 |
|---|---|
| WriteOperations | 2500/s弱で安定 |
| InnoDB pages written | 2000/s前後で安定 |
| 書き込み量 | 31.25 MB/s(16384 * 2000 / 1024 / 1024) innodb_page_sizeから推定。 |
| Network Bytes Received By MySQL | 26 MB/s前後で安定 |
| CPU Utilization | 60%前後で安定 |
ディスクサイズを２倍にしたが、IO性能は1.25倍にとどまった。
パターン7
パターン6と同じ環境で、２つのプロセスからデータをロードする。
結果
| 項目 | 値 |
|---|---|
| WriteOperations | 2800/s弱で安定 |
| InnoDB pages written | 2200/s前後で安定 |
| 書き込み量 | 34.375 MB/s(16384 * 2000 / 1024 / 1024) innodb_page_sizeから推定。 |
| Network Bytes Received By MySQL | 29 MB/sで安定 |
| CPU Utilization | 77~79% |
パターン6よりはIO性能が上昇したが、パターン4の2倍にはならなかった。（約1.4倍）
パターン8
ディスクサイズをさらに増やして、600GBにする。
| vCPU | メモリ | ディスクサイズ | 読み取りスループット(MB/秒) | 書き込みスループット(MB/秒) | 読み取り IOPS | 書き込み IOPS |
|---|---|---|---|---|---|---|
| 2 | 7.5 GB | 600GB | 288.0 | 151.5 | 15,000 | 15,000 |
結果
パターン6とほぼ同じ結果だった。つまり、ボトルネックがIOから別のところへ移ったといえそう。
メモ
書き込み量を推定
"InnoDB pages written" × "innodb_page_size"で推定可能。
"InnoDB pages written"はStackdriverから取得可能。"innodb_page_size"は、show variables;から取得可能。
参考資料
- ブロック ストレージのパフォーマンスの比較
- Cloud SQL 第 2 世代のパフォーマンスと機能を詳説
- Stackdriverのメトリクスについて
- CloudSQL ストレージの料金