So-net無料ブログ作成
  • ブログをはじめる
  • ログイン

Sambaサーバの性能が出ない その3 (2018/09/02) [仮想化]

前回の結果から、ちゃんとした性能検証も必要ということが分かりました。ベアメタル、XenServer、vSphereについてディスクI/Oの数値を調べてみます。

■ハードウェア環境
同じサーバの中身を入れ替えているので、ハード構成は同一です。
・CPU:Celeron J4105
・メモリ:8GB
・ハードディスク:TOSHIBA MD04ACA200(2TB)x 2本
・NIC:Realtek RTL8111H

■測定1■ gmirror設定直後
gmirrorでソフトウェアRAID1を設定する際、gmirror insertで2本目のディスクを指定します。この直後、2本目のディスクデータは、1本目のディスクデータで上書き(同期)されます。膨大なデータのディスクI/Oが連続長時間発生することになり、このときのiostat 1の数字を確認します。

ベアメタル) 70~80MB/s
XenServer) 30~40MB/s
vSphere)25~35MB/s


■測定2■ Sambaサーバへの書き込み(4GB程度の大きなファイル)
設定ファイルは全て同じものを流用しています。Sambaサーバがアクセスする場所は、いずれもディスクパーティーションを分けています。なお、これらは測定1のgmirrorのディスク同期が終わり、安定状態に入ってからの数字です。

ベアメタル) 90~110MB/s
XenServer) 30~40MB/s
vSphere)10~12MB/s

■測定2a■ ベアメタルでの転送速度の落ち込み
vSphereは明らかに遅いですし、XenServerはそこそこ性能が出るが性能の落ち込みが発生するため、残念ながらベアメタルで正式運用しようと考えました。折角購入したマザーボードも無駄だったのだなぁと。

本格的に利用を再開するため、真面目に500GBのデータリストアを行っていた訳ですが、500GBのデータをまとめてSambaサーバへコピーしたところ、なんと残り50GB程度の終盤で転送速度の落ち込みが発生することが分かりました。(0MB/sが発生して転送が一時的に止まる)
先日のXenServerではdom0のiowaitが明らかに異常値でしたが、ベアメタルのFreeBSD上でiostat やvmstatでいろいろな数値を見たのですが、特にボトルネックとなるようなものは見当たらず、原因は本当に謎です。転送速度の急激な落ち込みは、XenServerだけが悪いといった訳ではなかったのかもしれません。


■測定3■ Sambaサーバへの書き込み2
測定を行っていると、XenServerでも安定して90~110Mbpsの速度が出るケースが発生しました。それは測定が終わり、測定に使ったファイルを消して再測定する場合です。
キャッシュも考えられますが、上記の速度が安定して10分以上発生し続けるため、容量からして、キャッシュではないことは明かです。

XenServer) 90~110Mbps

状況から察するに、XenServer側で提供している仮想ストレージに秘密を解く鍵がありそうです。
一つの仮説として、新規に使用する仮想ストレージ領域は、領域確保→論理フォーマットを行ってからセクタを提供するといったオーバーヘッドが発生しているため、性能が出ないのではないかということです。
Sambaにおいて、測定に使用したファイルを削除し再測定する場合は、領域確保→論理フォーマットのオーバーヘッド部分がないため、本来の性能が出るのではないかと考えました。(OS側のクイックフォーマットなんかも関係している?)

それを裏付ける数字として、XenCenterで確認できる仮想ストレージのサイズとして、測定の1のgmirrorの完了直後の数字が下記のようになっていました。仮想ストレージAとBは、gmirrorで完全同期しているため同じ使用量になるはずですが、見ての通り明らかに違うのです。
・仮想ストレージA:1.6TB使用/1.6TB中
・仮想ストレージB:8G使用/1.6TB中
そして、Sambaの測定が終わってファイルを削除した後は、仮想ストレージBの使用量が100GBといったように明らかに使用分だけ増えているのです。


■測定4■ Sambaサーバへの書き込み3
なんとなく動きが分かってきたので、Sambaへ同様にファイルをコピーします。ただし、今回は100GB程度の転送後に一度キャンセルし、データを削除してから再びファイルをコピーします。

XenServer ~100GBまでの領域) 90~110MB/s
XenServer 100GB以降の領域) 30~40MB/s

ここまでくれば事象は解明できたようなものです。


■測定5■ ddでダミーファイルの書き込み
ダメ押しの測定です。dd if=/dev/zero of=./hoge.dummy bs=1G count=1000として、1TBのダミーファイルを書き込みます。Sambaと同じように途中でキャンセル&ファイルの削除を行い、何度か繰り返すことで、論理フォーマットされた領域での速度と、新規に確保する領域での速度の違いを測定します。

論理フォーマットされた領域での数値
root@mybsd:~ # iostat 1
       tty            ada0             ada1              cd0             cpu
 tin  tout  KB/t tps  MB/s   KB/t tps  MB/s   KB/t tps  MB/s  us ni sy in id
   0    82 31.98 4192 130.95  31.99 4230 132.14   0.00   0  0.00   0  0  3  0 97
   0    82 31.98 4167 130.16  31.98 4125 128.83   0.00   0  0.00   0  0  3  0 96
   0    82 31.99 3995 124.78  31.98 3985 124.44   0.00   0  0.00   0  0  2  0 98
   0    82 31.99 3778 117.99  31.99 3828 119.58   0.00   0  0.00   0  0  4  0 96
   0    82 32.00 4292 134.12  32.00 4261 133.15   0.00   0  0.00   0  0  3  0 97
   0    82 31.94 4061 126.66  31.95 4047 126.25   0.00   0  0.00   0  0  3  0 97
   0    82 31.97 4186 130.71  31.97 4185 130.68   0.00   0  0.00   0  0  3  0 96
   0    82 32.00 3674 114.82  32.00 3611 112.83   0.00   0  0.00   0  0  7  0 93
   0    82 32.00 4152 129.76  32.00 4151 129.73   0.00   0  0.00   0  0  4  0 96
   0    82 32.00 4274 133.57  32.00 4161 130.04   0.00   0  0.00   0  0  3  0 97
   0    82 32.00 4677 146.18  32.00 4869 152.15   0.00   0  0.00   0  0  4  0 96
   0    83 31.99 4092 127.83  31.99 4071 127.17   0.00   0  0.00   0  0  1  0 99
   0    81 31.98 3504 109.41  31.98 3542 110.62   0.00   0  0.00   0  0  3  0 97
   0    82 32.00 3927 122.73  32.00 3895 121.72   0.00   0  0.00   0  0  3  0 97

新規に確保する領域での数値
root@mybsd:~ # iostat 1
       tty            ada0             ada1              cd0             cpu
 tin  tout  KB/t tps  MB/s   KB/t tps  MB/s   KB/t tps  MB/s  us ni sy in id
   0    80 31.96 1233 38.48  31.95 1244 38.82   0.00   0  0.00   0  0  2  0 98
   0    82 31.99 1573 49.16  31.99 1573 49.16   0.00   0  0.00   0  0  1  0 99
   0    78 31.96 1099 34.31  31.93 1136 35.44   0.00   0  0.00   0  0  2  0 98
   0    80 31.95 1154 36.00  31.98 1150 35.92   0.00   0  0.00   0  0  2  0 98
   0    80 31.98 1282 40.04  31.96 1283 40.04   0.00   0  0.00   0  0  1  0 98
   0    80 31.97 1329 41.49  31.98 1219 38.07   0.00   0  0.00   0  0  1  0 99
   0    80 31.99 1268 39.60  31.98 1314 41.04   0.00   0  0.00   0  0  1  0 99
   0    75 31.98 1310 40.91  31.96 1308 40.83   0.00   0  0.00   0  0  1  0 99
   0    84 31.98 1551 48.42  31.98 1551 48.42   0.00   0  0.00   0  0  1  0 98
   0    80 32.00 1499 46.85  31.99 1467 45.84   0.00   0  0.00   0  0  1  0 99
   0    76 31.98 1164 36.35  31.99 1225 38.26   0.00   0  0.00   0  0  1  0 99
   0    83 31.99 1395 43.58  31.99 1329 41.51   0.00   0  0.00   0  0  1  0 99
   0    77 31.92 1140 35.53  31.91 1169 36.43   0.00   0  0.00   0  0  1  0 99
   0    80 31.98 1129 35.24  31.98 1129 35.24   0.00   0  0.00   0  0  2  0 98
   0    80 31.98 1223 38.20  31.98 1223 38.20   0.00   0  0.00   0  0  2  0 98

ddはそのまま動作させ続けているのですが、新規に確保する領域に入った途端、後者のような数字に落ち込むので、非常に分かりやすい結果となりました。
上記のような話は概念的には知っていましたが、実際の数字を見ると面白いですね。仮想ストレージにおいて、ファイル容量の節約も重要ですが、性能がトレードオフになることも覚えておかないといけません。

タグ:XenServer
nice!(0)  コメント(0) 
共通テーマ:日記・雑感

nice! 0

コメント 0

コメントを書く

お名前:
URL:
コメント:
画像認証:
下の画像に表示されている文字を入力してください。