[gfarm-discuss-ja:00090] Re: gfarm 速度調査

[Osamu Tatebe <o.tatebe@xxxxxxxxxx>]

松尾さま：

削除の時間もも，先の slapd の最適化でずいぶん改善されるはずです．また，
ドキュメントしていませんが，

% gfrm -R * & gfrm -R * & gfrm -R * & gfrm -R * & gfrm -R * &

などとすることにより，5並列で消去可能です．

FC3 の binary package は，パッケージのミスのようですね．確認します．

自作の負荷ツールで，fuse ではだめでシステムコールフックライブラリでは
OK の件です．ちょっと，どういう状況でそういうことが起るのか，検討がつ
きません．同一ユーザで実行していますでしょうか？ gfarmfs をマウントし
直しても状況は変りませんでしょうか？ 

ls の時間ですが，gfarm_agent を利用すると，二度目以降のがはやくなりま
す．また，一回目も最適化により遅くとも数秒で終わるはずです．

建部＠産総研

>> On Sun, 18 Sep 2005 22:12:09 +0900, Matsuo Akihiro <matsuo@xxxxxxxxxxxx> said:

>> おつかれさまです、ドワンゴの松尾壮紘です
>> ML で長々と書く物じゃない気がするので
>> 明日から wiki 起こしてそっちに書くようにしますので、
>> 今回まで長文での ML 汚しご容赦ください。



>> 今日の作業内容


>> ０．準備
>> 昨日までのファイルは全部削除し、
>> メタサーバ１台、ファイルノード１台、クライアント１台で実験

>> 参考までに昨日のファイル
>> filenode01   3447
>> filenode02  25552
>> filenode03  13868
>> 合計 42867 ファイルを以下のコマンドで削除

>> # time -p gfrm -R *

>> 削除にかかった時間 real 18930.62 秒 (約６時間)



>> １．gfarm-1.2-4 へのアップグレード

>> http://datafarm.apgrid.org/software/1.2/fc3/1.2-4/
>> FedoraCore3 用の RPM でアップデートしようとしたが、
>> rpm でアップデートしようとすると
>> FedoraCore3 には無いライブラリを要求されインストールできない
>> -------------------------------------------------------------------
>> # rpm -Uvh gfarm-gsi-client-1.2-4.i386.rpm gfarm-gsi-fsnode-1.2-4.i386.rpm gfarm-gsi-libs-1.2-4.i386.rpm
>> error: Failed dependencies:
>>         libcrypto_gcc32.so.0 is needed by gfarm-gsi-client-1.2-4.i386
>>  libglobus_common_gcc32.so.0 is needed by gfarm-gsi-client-1.2-4.i386
>>         libcrypto_gcc32.so.0 is needed by gfarm-gsi-fsnode-1.2-4.i386
>> ・・・
>> 以下 *gcc32.so のライブラリを大量に求められるが
>> FedoraCore3 には存在しない
>> -------------------------------------------------------------------



>> ２．gfarm 1.2-5
>> 実はこっそり 1.2-5 が用意されていたので、
>> source RPM から rpmbuild してアップデートを行った

>> 問題なく最新版にバージョンアップ完了



>> ３．fuse 上のファイルが自作の負荷ツールから読めない

>> 自作で、あるディレクトリ以下の
>> ・ファイルリストを作るツール
>> ・ファイルリストを元にファイルを読み出すツール
>> を作り、負荷試験用に用いていますが、

>> ファイルリストを作るツールは問題ないが、
>> ファイルリストを元に読み出すツールから gfarm 上のファイルが読めない
>> あれこれチェックしてもらったが、原因が分からずじまい

>> 調査した結果から分かった事は
>> ---
>> client サーバからだと fuse 上のファイルをツールから読めない
>> meta サーバからだと fuse 上のファイルをツールから読める
>> ---
>> fuse 上のファイルはツールから読めないが (/tmp/fuse/)
>> システムコールフックライブラリを使えばツールから読める (/gfarm)
>> ---
>> ということが、分かったので、
>> gfarm パッケージの追加インストールや、
>> 環境設定(おまじない)を見直してみたが症状が改善されない為、
>> システムコールを使ってのテストに切り替え。



>> ４．ファイルコピー速度比較 「fuse」 vs 「system call hook」

>> シェル上で普通にローカルディスクにある元ファイルを
>> gfarm 上に cp -a した場合にかかった時間

>> -- fuse
>>  100 ファイル  143秒 157秒 148秒
>> 1000 ファイル 1431秒

>> -- システムコールフック
>>  100 ファイル   74秒  78秒  79秒秒
>> 1000 ファイル  815秒


>> 100 ファイルコピーは３回連続テスト
>> コピー時のメモリキャッシュを考慮したがあまり影響は無い模様、
>> 1ファイルは約 1KB 前後



>> ５．ls が表示されるまでの時間
>> gfarm 上の登録ファイル数 1100

>> --- ls 速度比較
>> -- fuse
>> time -p ls /tmp/fuse/root/testfile (結果2件)
>>  6.69秒 0.02秒 0.03秒 

>> time -p ls /tmp/fuse/root/testfile/test100/ (結果100件)
>> 14.72秒 7.67秒 8.53秒

>> -- system call hook
>> time -p ls /gfarm/root/testfile/ (結果2件)
>>  7.02秒 7.25秒 5.61秒

>> time -p ls /gfarm/root/testfile/test100 (結果100件)
>>  14.86秒 13.97秒 14.26秒


>> ※fuse の方が２回目以降はキャッシュが効くので速い

>> ls の表示速度から見る結果 (fuse の場合)
>> 総ファイル数
>>  1100ファイル      8秒
>> 31500ファイル    230秒  (昨日のテスト結果)

>> 8秒 x 28.6 = 229秒 なので、
>> 総ファイル数が増えると、ほぼリニアに応答時間が増える




>> 最後に気になる点
>> meta サーバがひたすら io write していること。
>> SWAP は発生していない
>> client から ls すると、結果が返ってくるまでひたすら
>> meta サーバ上で io write が発生している理由が判らない


>> 以上、

>> 明日からは自作ツールを使いファイル読み込みにかかる時間と
>> クライアント台数を増やした場合の性能劣化を測定予定


>> 長文失礼しました。
>> ―[ Dwango ]―――――――――――――――――――――――
>> /株式会社ドワンゴ/京都研究開発センター/\
>> 松尾壮紘 - Mail : matsuo@xxxxxxxxxxxx
>> ―――――――――――――――――――――――――――――