スマートスタイル TECH BLOG

データベース&クラウド技術情報

stress-ngコマンドを使ったCPU高負荷時のMySQL性能試験

はじめに

MySQLが稼働するDBサーバでは、可能な限りMySQL以外のプロセスは稼働していない状況が推奨されます。それはプロセス間のサーバリソース(CPU、メモリなど)の競合や、問題発生時の原因切り分けの煩雑さを避けるためです。
とはいえ、実際には諸々の事情から、他のプロセスと同居させざるを得ないケースもあるかと思います。

その場合、他プロセスが予期せぬ挙動でCPUリソースの大部分を使用してしまい、MySQLが割を食ってしまうことも考えられます。本稿では、そうしたケースを想定したMySQL性能試験について触れたいと思います。

stress-ng について

意図的なCPU負荷をかけるツールは様々ありますが、今回は「stress-ng」コマンドを使用します。
このコマンドは、公式マニュアルの記述の通り、200種類以上ものストレステストを実現できます。また、大半のLinuxに対応しており非常に高い汎用性を有しています。

テスト概要

Oracle公式リポジトリからyumインストールしたMySQL8.0.14に対して、sysbenchで read_write の負荷試験を行います。
その際に、stress-ngコマンドを使って負荷をかけるCPUコア数を 0コア → 2コア → 4コア → 6コア → 8コア と引き上げていき、sysbenchのスコアの変動を確認します。

環境構築

この試験では、以下のようなサーバを使用します。

vCPU : 8 core
RAM : 64GB

MySQL8.0.14をインストールし、起動します。

※ my.cnfには以下の項目だけ追加しています

次に、sysbench 1.0をインストールします。

stress-ngコマンドは、epel リポジトリに含まれています。もしインストールされていない場合はリポジトリを準備してから、stress-ngコマンドをインストールしましょう。

テスト手順

まずはsysbenchのデータをロードします。
–table-size = 1000000 / –tables = 10 オプションをつければ、100万行のテストテーブルが10個作られます。

ロード後のデータディレクトリは丸ごとバックアップとして任意の場所にコピーします。
ベンチマーク実行後、このバックアップを毎回リストアしてテストを繰り返します。

準備が完了したら、以下の4パターンでベンチマークを実施します。
同じ試験を2回ずつ行います。なお、sysbenchのコマンドは全て同じです。

① stress-ng 実行なし
② stress-ng 実行(2コア)
③ stress-ng 実行(4コア)
④ stress-ng 実行(6コア)
⑤ stress-ng 実行(8コア)

【stress-ng のオプション】

・–cpu:CPUの負荷試験を行う場合に指定する。数値には使用するCPUのコア数を指定する。
・-l:CPUの使用率を指定する。今回は90%に固定する。
・-t:実行時間を指定する。今回はsysbenchよりも長い15分(15m)に固定する。

※ 2コアを使用するstress-ngコマンドの実行例(sysbench実行前に行う)

topコマンド → “1”を入力、でコアごとの使用率を見ると以下のようになります。

【sysbench 実行コマンド】

テスト結果

    TPS QPS Latency (avg)
① stress-ng 実行なし 1回目 890.98 17819.68 33.66 ms
① stress-ng 実行なし 2回目 904.07 18081.58 33.18 ms
② stress-ng 実行(2コア)1回目 822.36 16447.33 36.47 ms
② stress-ng 実行(2コア)2回目 827.55 16551.16 36.24 ms
③ stress-ng 実行(4コア)1回目 706.80 14136.06 42.44 ms
③ stress-ng 実行(4コア)2回目 677.57 13551.51 44.27 ms
④ stress-ng 実行(6コア)1回目 594.39 11887.96 50.46 ms
④ stress-ng 実行(6コア)2回目 580.92 11618.44 51.63 ms
⑤ stress-ng 実行(8コア)1回目 515.01 10300.22 58.24 ms
⑤ stress-ng 実行(8コア)2回目 501.54 10030.79 59.80 ms

追加テスト

折角なので、以下のパターンも計測してみました。

⑥ stress-ng 実行(8コア, 20%)
⑦ stress-ng 実行(8コア, 40%)
⑧ stress-ng 実行(8コア, 60%)
⑨ stress-ng 実行(8コア, 80%)
⑩ stress-ng 実行(8コア, 100%)

結果は以下の通りです。

    TPS QPS Latency (avg)
⑥ stress-ng 実行(8コア, 20%)1回目 842.71 16854.33 35.59 ms
⑥ stress-ng 実行(8コア, 20%)2回目 790.72 15814.42 37.93 ms
⑦ stress-ng 実行(8コア, 40%)1回目 739.10 14782.17 40.58 ms
⑦ stress-ng 実行(8コア, 40%)2回目 716.16 14323.36 41.88 ms
⑧ stress-ng 実行(8コア, 60%)1回目 648.75 12975.13 46.23 ms
⑧ stress-ng 実行(8コア, 60%)2回目 631.46 12629.26 47.50 ms
⑨ stress-ng 実行(8コア, 80%)1回目 557.09 11141.96 53.84 ms
⑨ stress-ng 実行(8コア, 80%)2回目 540.26 10805.37 55.52 ms
⑩ stress-ng 実行(8コア, 100%)1回目 339.04 6780.82 88.47 ms
⑩ stress-ng 実行(8コア, 100%)2回目 328.70 6574.01 91.25 ms

まとめ

上記のように、CPUの負荷をあげるにつれてsysbenchのスコアが低くなっていることが分かります。これはstress-ngコマンドではなく、通常のアプリケーションであっても、スコア低下率に差はあれ同様の傾向がみられると考えられます。
もし、DBサーバにMySQL以外のプロセスを同居させる場合は注意してください。

しかし、一方でCPU負荷が高い状態でもMySQLは一定以上の性能が出せることも確認できました。もし、MySQLの最低限の性能をみたいケースなどでも、こうした性能試験は便利そうです。

stress-ngコマンドはCPU以外にも様々な負荷シナリオを実現できます。もしよければお手元のMySQLサーバで色々と試してみてください。

MySQL

 

Return Top