環境
項目 | 設定 |
---|---|
OS | AmazonLinux (version 2017.03) |
インスタンスタイプ | t2.micro |
ボリュームタイプ | gp2 |
pythonバージョン | Python 3.5.3 (pyenv) |
AWS CLIバージョン | aws-cli/1.11.82 |
goofysバージョン | 0.0.10 |
s3fsバージョン | V1.80 |
goofysのインストール
こちらの記事を参考にさせてもらいました。
goofysを使ってAmazon LinuxにS3をマウントする。
# yum install golang fuse
# export GOPATH=$HOME/go
# go get github.com/kahing/goofys
# go install github.com/kahing/goofys
exportのところは、/root/.bash_profileの末尾に書き足してsourceした。
インストールできたのでバージョンを確認。結構若い。
[root@ip-172-30-0-5 ~]# ./go/bin/goofys --version
goofys version 0.0.10
これ、/usr/sbinかなんかの下に入れたほうがよかったな。
mvしてやろうと思ったけどgoのこと詳しくないからとりあえず触らないでおこう…ださいけど。
では、マウント。
[root@ip-172-30-0-5 ~]# /root/go/bin/goofys jucco-s3-speed-test /goofys
[root@ip-172-30-0-5 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 488M 56K 488M 1% /dev
tmpfs 497M 0 497M 0% /dev/shm
/dev/xvda1 7.8G 2.3G 5.5G 30% /
jucco-s3-speed-test 1.0P 0 1.0P 0% /goofys
特にレスポンス無しでマウントが完了。
s3fsのインストール
本家の手順で実施。
https://github.com/s3fs-fuse/s3fs-fuse
# yum install automake fuse fuse-devel gcc-c++ git libcurl-devel libxml2-devel make openssl-devel
# git clone https://github.com/s3fs-fuse/s3fs-fuse.git
# cd s3fs-fuse
# ./autogen.sh
# ./configure
# make
# make install
[root@ip-172-30-0-5 s3fs-fuse]# s3fs --version
Amazon Simple Storage Service File System V1.80(commit:f02b1bc) with OpenSSL
Copyright (C) 2010 Randy Rizun <rrizun@gmail.com>
License GPL2: GNU GPL version 2 <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
成功したっぽい。こっちは/usr/local/bin/s3fs
にファイルを発見。
では、マウント。とりあえずオプションは最低限。なんでIAM Role名指定するんだろう…。
[root@ip-172-30-0-5 s3fs-fuse]# s3fs jucco-s3-speed-test /s3fs -o iam_role=administrator
[root@ip-172-30-0-5 s3fs-fuse]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 488M 56K 488M 1% /dev
tmpfs 497M 0 497M 0% /dev/shm
/dev/xvda1 7.8G 2.3G 5.4G 30% /
jucco-s3-speed-test 1.0P 0 1.0P 0% /goofys
s3fs 256T 0 256T 0% /s3fs
まず使える容量としてはgoofysが上。ペタバイトかぁ。
簡易測定
ddコマンドで測ってみる。
time dd if=/dev/zero of=<path>/1024MB.tmp ibs=1M obs=1M count=1024
結果1 : ddコマンドで比較
goofys | s3fs | local disk |
---|---|---|
56.3 MB/s | 30.1 MB/s | 74.2 MB/s |
おおっ、確かに全然違う。
AWS CLIとも比較してみたかったので、平等にローカルディスクからコピーする時間を比較してみた。
time cp /root/1024MB.tmp <path>/
or
time aws s3 cp /root/1024MB.tmp s3://jucco-s3-speed-test/
結果2 : cpコマンドで比較
goofys | s3fs | aws s3 cp | local disk |
---|---|---|---|
0m21.362s | 0m36.652s | 0m19.168s | 0m15.783s |
goofysよりもaws cliが早いのは、file systemとして動かすための余計な処理が挟まっているからかな。
まあでもs3fsと比べるとそんなに大したズレでもないか。
bonnie++で測定
こちらを参考にしました。
https://hesonogoma.com/linux/UsageOfBonnie.html
# wget http://www.coker.com.au/bonnie++/bonnie++-1.03e.tgz
# tar xf bonnie++-1.03e.tgz
# cd bonnie++-1.03e
# ./configure
# vi bonnie.h
※#define MinTime (0.5) → #define MinTime (0.01)
# make
あとから気づいたけどrpmも転がっている系だったのか…
ともあれ、makeが完了。
[root@ip-172-30-0-5 bonnie++-1.03e]# ./bonnie++ help
usage: bonnie++ [-d scratch-dir] [-s size(MiB)[:chunk-size(b)]]
[-n number-to-stat[:max-size[:min-size][:num-directories]]]
[-m machine-name]
[-r ram-size-in-MiB]
[-x number-of-tests] [-u uid-to-use:gid-to-use] [-g gid-to-use]
[-q] [-f] [-b] [-D] [-p processes | -y]
Version: 1.03e
こんな感じで測定する。
./bonnie++ -d <path> -n 256:1024:1024:16 -u root
-n
のところは「ファイル数 256*1024、最大ファイルサイズ 4096byte、最小ファイルサイズ 512byte、ディレクトリ数 16」という意味らしい。
→やたら時間かかるから途中から-n
オプション消した。(が、これがのちに失敗だったことに気づく。測定結果には関係ないけど。
結果をはりたかったけど
早速goofysの測定でコケた。
[root@ip-172-30-0-5 bonnie++-1.03e]# ./bonnie++ -d /goofys -n 256:1024:1024:16 -u root
Using uid:0, gid:0.
Writing with putc()...done
Writing intelligently...done
Rewriting...Can't read a full block, only got 0 bytes.
Can't read a full block, only got 0 bytes.
Bad seek offset
Error in seek(0)
ファイル読み込みに失敗?タイムアップなので今度リトライしてみよう。
[2017/5/5 追記]
bonnie++のソースをgrepしてみたら、とりあえずreadって関数で落ちたみたい。
たぶんこれ。
Man page of READ
ssize_t read(int fd, void *buf, size_t count);
read() はファイルディスクリプター (file descriptor) fd から最大 count バイトを buf で始まるバッファーへ読み込もうとする。
goofysくんはこの関数のリクエストをうまくハンドリングできないってことなのかな…
にわか知識でこれ以上コメントしたくないので、とりあえず期待通りに動作してくれないケースがあることがわかっただけで良しとしよう。
結果3 : bonnie++で比較
s3fsのほうはbonnie++でちゃんと測定できたのでlocal diskと比較。
分類 | 項目 | 単位 | s3fs | local disk |
---|---|---|---|---|
Sequential Output | Per Chr | K/sec | 28,616 | 67,706 |
Block | K/sec | 30,211 | 67,248 | |
Rewrite | K/sec | 24,039 | 59,861 | |
Sequential Input | Per Chr | K/sec | 24,015 | 62,497 |
Block | K/sec | 29,827 | 62,503 | |
Random | Seeks | /sec | 72.8 | 10,965 |
Sequential Create | Create | /sec | 7 | 141,305 |
Read | /sec | 69 | 1,177,106 | |
Delete | /sec | 27 | 183,235 | |
Random Create | Create | /sec | 6 | 143,461 |
Read | /sec | 94 | 98 | |
Delete | /sec | 29 | ※ |
※結果が早すぎて測定不可だった。オプションの指定が悪かった。
差がすごい…
特にRandom Create(時間あたりに作成可能なランダムな命名規則のファイル…だと思う)にいたっては23,910倍。
これは使い道を限定するなぁ。
生ログはこちら。
■s3fs
Version 1.03e ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
ip-172-30-0-5 2G 28616 28 30211 2 24039 1 24015 22 29827 0 72.8 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 7 0 69 0 27 0 6 0 94 0 29 0
ip-172-30-0-5,2G,28616,28,30211,2,24039,1,24015,22,29827,0,72.8,0,16,7,0,69,0,27,0,6,0,94,0,29,0
■local disk
Version 1.03e ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
ip-172-30-0-5 2G 67706 64 67248 3 59861 3 62497 60 62503 1 10965 9
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 141305 100 1177106 86 183235 98 143461 98 +++++ +++ 185059 99
ip-172-30-0-5,2G,67706,64,67248,3,59861,3,62497,60,62503,1,10965.1,9,16,141305,100,1177106,86,183235,98,143461,98,+++++,+++,185059,99
s3fsは遅すぎて(?)CPU負荷があまりあがってない模様。都度AWS API発行 + NWネックで遅くなっている気がする。
この記事はこのへんでー。