ちゃんと出来てると思ってたことが、実はちゃんと出来てなくて愕然とすることってありませんか。
僕にはよくあります。つい最近もありました。
そんな今日このごろ、皆さまいかがお過ごしでしょうか。
前にGCS fuseのベンチマークを取ったんですが、どうもやり方が良くないところがあったり、実はStandardとDRAでリージョン違うとこ使ってたらしいということが発覚し、やり直してみました。
ちなみに前のテスト結果は以下の記事。
[GCP] GCS Fuseのベンチマークを取ってみた
まず根本的なテスト条件。
そこで、今回はランダムデータで書きだしたファイルをコピーするようにしました。
ddコマンドでランダムデータを書き込むのでも良いのかもしれませんが、ランダムデータの生成に時間がかかるためGCS fuseの性能よりそちらで制限がかかってしまいそうなので、あらかじめ生成したファイルのコピー時間から計算するようにしました。
ファイルは以下のコマンドでランダムなデータによる1GBのファイルを生成しました。
生成したファイルをcpコマンドでコピーする時間をtimeコマンドを使用し計測しました。
1024MB/コマンド実行時間 で転送速度を算出しています。
なお、以下の結果は5回行ったものの平均を出しています。
前回とほとんど変わらないので、どうやら圧縮は効いていないようです。
前回はDRAの方が性能が良かったですが、今回はあまり大きな差がありません。
実は前回はStandardをAsiaじゃなくてEUで作ってたという大ポカをやらかしていました。
すんません。
そら性能出ませんわー。
前回の訂正だけだとつまらないので、もうちょっとテストをしてみました。
GCS fuseはマルチスレッド転送をするらしいので、もしかしたらCPUが増えたら性能が上がるのでは? と思い、n1-standard-4でもテストしてみました。
その結果がこちら。
…一体何が起こったんでしょうか。
2コアから4コアに増えたので、性能が2倍になっても良さそうなのに、むしろ半減。
topコマンドで処理の様子を眺めてみると、gcsfuseの消費するCPUリソースが100%。
ただ、これ複数CPUに25%づつぐらいになってたりするんですよね。
つまりCPU1個分だけの負荷にしかなっていない。
どうもシングルスレッドで動いている部分でCPUスイッチする分無駄が出ている気配。
gcsfuseコマンドに--debug_fuseとか--debug_gcsオプションつけてdebug出力でもすればなにかわかるかもしれませんが…。
追いかける時間もないのでどうにも中途半端ですが、今のところCPUコアの多いマシンでGCS fuseを使わないほうが良さそうです。
この辺はgcsfuseのバージョンが上がったらまたテストしてみたいところです。
そんなところで今回はここまで。
僕にはよくあります。つい最近もありました。
そんな今日このごろ、皆さまいかがお過ごしでしょうか。
前にGCS fuseのベンチマークを取ったんですが、どうもやり方が良くないところがあったり、実はStandardとDRAでリージョン違うとこ使ってたらしいということが発覚し、やり直してみました。
ちなみに前のテスト結果は以下の記事。
[GCP] GCS Fuseのベンチマークを取ってみた
まず根本的なテスト条件。
- テスト用インスタンスをn1-standard-2でasia-east1-aに作成
- OSはUbuntu 14.04.3 LTS (GNU/Linux 3.19.0-43-generic x86_64)
- gcsfuseはversion 0.15.1 (Go version go1.5.2)
- StandardとDurable Reduced AvailabilityのBucketをasiaリージョンで作成
そこで、今回はランダムデータで書きだしたファイルをコピーするようにしました。
ddコマンドでランダムデータを書き込むのでも良いのかもしれませんが、ランダムデータの生成に時間がかかるためGCS fuseの性能よりそちらで制限がかかってしまいそうなので、あらかじめ生成したファイルのコピー時間から計算するようにしました。
ファイルは以下のコマンドでランダムなデータによる1GBのファイルを生成しました。
dd if=/dev/urandom of=test.tmp bs=1M count=1024
生成したファイルをcpコマンドでコピーする時間をtimeコマンドを使用し計測しました。
1024MB/コマンド実行時間 で転送速度を算出しています。
なお、以下の結果は5回行ったものの平均を出しています。
GCS Type | 転送速度平均値(MB/sec) |
---|---|
Standard | 49.0 |
Durable Reduced Availability | 43.7 |
前回とほとんど変わらないので、どうやら圧縮は効いていないようです。
前回はDRAの方が性能が良かったですが、今回はあまり大きな差がありません。
実は前回はStandardをAsiaじゃなくてEUで作ってたという大ポカをやらかしていました。
すんません。
そら性能出ませんわー。
前回の訂正だけだとつまらないので、もうちょっとテストをしてみました。
GCS fuseはマルチスレッド転送をするらしいので、もしかしたらCPUが増えたら性能が上がるのでは? と思い、n1-standard-4でもテストしてみました。
その結果がこちら。
GCS Type | 転送速度平均値(MB/sec) |
---|---|
Standard | 24.0 |
Durable Reduced Availability | 26.7 |
…一体何が起こったんでしょうか。
2コアから4コアに増えたので、性能が2倍になっても良さそうなのに、むしろ半減。
topコマンドで処理の様子を眺めてみると、gcsfuseの消費するCPUリソースが100%。
ただ、これ複数CPUに25%づつぐらいになってたりするんですよね。
つまりCPU1個分だけの負荷にしかなっていない。
どうもシングルスレッドで動いている部分でCPUスイッチする分無駄が出ている気配。
gcsfuseコマンドに--debug_fuseとか--debug_gcsオプションつけてdebug出力でもすればなにかわかるかもしれませんが…。
追いかける時間もないのでどうにも中途半端ですが、今のところCPUコアの多いマシンでGCS fuseを使わないほうが良さそうです。
この辺はgcsfuseのバージョンが上がったらまたテストしてみたいところです。
そんなところで今回はここまで。
コメント
コメントを投稿