|
|
前のページ 1 2 3
|
|
設定ファイルの作成
|
次に「~/share/select-key.smack」を編集し、先ほどMySQLサーバ側で指定した内容と呼応するように設定を変更します。
変更前 |
変更後 |
host "localhost"; |
host "$HOST"; |
pass ""; |
pass "$PASSWD"; |
user "test"; |
user "root"; |
pass ""; |
pass "$PASSWD"; |
host "localhost "; |
host "$HOST"; |
表3:変更する項目
|
super-smackコマンドの実行
|
それでは実際に負荷をかけてみましょう。super-smackコマンドを使用しますが、オプションは「設定ファイル」「スレッド数」「1スレッドごとのクエリ数」の順に指定します。
図3:負荷テストを実行 (画像をクリックすると別ウィンドウに拡大図を表示します)
super-smackの処理が完了すると、MySQLサーバの性能に関する情報が表示されます。もっとも端的にMySQLサーバの性能をあらわすのは「q_per_s(Queries Per Second)」です。上記の場合「1秒当たり1419.10件のクエリを処理できる」となります。
|
デフォルト状態での負荷テスト
|
まずはデフォルト状態での負荷テストを行います。今回は、以下のようなテストを実施しました。
- 同時接続数を10,20,30…と増やして400まで測定し、q_per_sを収集
- 1スレッドごとのクエリ数は100に固定
- 各同時接続数は3回ずつ測定
- 測定間は10秒間インターバルをとる
表4:テストの実施要綱
super-smackのコマンドとしては以下のように実行しました。
「super-smack ~/share/select-key.smack 10 100」で3回測定
「super-smack ~/share/select-key.smack 20 100」で3回測定
…
「super-smack ~/share/select-key.smack 400 100」で3回測定
測定の際には、他の要因を排除するため、MySQLサーバでは、MySQLの処理に関係無いサービスはすべて停止しました。また、測定中は収集スクリプトを多少改造して、10秒間のsleepを挟んで連続的に実行させ、show statusの情報を収集しました。
|
テスト結果をグラフ化
|
以下の通り、測定結果をグラフ化しました。
図4:MySQLがデフォルト状態の測定結果 (画像をクリックすると別ウィンドウに拡大図を表示します)
各軸は以下の通りです。
- X軸:時間経過(hh:mm)
- 左側Y軸:Max_used_connectionsもしくはThreads_createdの数
- 右側Y軸:Queries_per_sec
表5:グラフの軸の項目
max_connectionsの推移を見ると、途中で100に達してしまい、同時接続数400まで測定できませんでした。
グラフに縦線を引きましたが、これはQueries_per_secが安定しているかどうか、の境界線をあらわしています。境界線手前では良好な応答速度で処理できており、境界線以降はばらつきが大きく、数値も低下しています。
そうしてみると、Queries_per_secは同時接続数が少ない間は1200程度を中心値として安定していますが、緑色の線を引いたあたりの測定以降、明らかに低下傾向にあります。また、Query_per_secが低下する直前のmax_connectionsは94でした。
|
次回は
|
今回はデフォルト状態での負荷テストを実施しました。次回以降はこれを基本データとして、チューニングによってどのようにパフォーマンスが変化するか、を検証してゆきます。
|
前のページ 1 2 3
|
|
|
|
著者プロフィール
株式会社アールワークス 田中 靖之
ネットワークインテグレーション部 主にWebサービス系のシステム運用監視を担当するネットワークインテグレーション部に所属。システム改善やチューニングを顧客と共に考える姿勢を大事にしている。
|
|
|
|