[GCP] GCS Fuseのベンチマークを取ってみた (改訂版)

ちゃんと出来てると思ってたことが、実はちゃんと出来てなくて愕然とすることってありませんか。
僕にはよくあります。つい最近もありました。
そんな今日このごろ、皆さまいかがお過ごしでしょうか。

前に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コマンドで書き込み速度をテストしましたが、書き込みデータが/dev/zeroから読み込んでいる0のデータなので、実は圧縮が効いているんではないかという疑問が。
そこで、今回はランダムデータで書きだしたファイルをコピーするようにしました。
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のバージョンが上がったらまたテストしてみたいところです。

そんなところで今回はここまで。