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と同じように途中でキャンセル＆ファイルの削除を行い、何度か繰り返すことで、論理フォーマットされた領域での速度と、新規に確保する領域での速度の違いを測定します。
論理フォーマットされた領域での数値
新規に確保する領域での数値
ddはそのまま動作させ続けているのですが、新規に確保する領域に入った途端、後者のような数字に落ち込むので、非常に分かりやすい結果となりました。
上記のような話は概念的には知っていましたが、実際の数字を見ると面白いですね。仮想ストレージにおいて、ファイル容量の節約も重要ですが、性能がトレードオフになることも覚えておかないといけません。
■ハードウェア環境
同じサーバの中身を入れ替えているので、ハード構成は同一です。
・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 98ddはそのまま動作させ続けているのですが、新規に確保する領域に入った途端、後者のような数字に落ち込むので、非常に分かりやすい結果となりました。
上記のような話は概念的には知っていましたが、実際の数字を見ると面白いですね。仮想ストレージにおいて、ファイル容量の節約も重要ですが、性能がトレードオフになることも覚えておかないといけません。
コメント 0