[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

松尾さま：

ワークショップではいろいろとありがとうございました．また，速度調査のご
報告ありがとうございます．

まず，10万ファイル近くを扱う場合は，以下のような最適化が必要になります．
＃ Gfarm-FAQ.ja の性能チューニングの項にも若干の記述がありますので，そ
＃ ちらも参照してください．

1. OpenLDAP サーバの最適化
2. gfarm_agent の利用

-----
1. OpenLDAP サーバの最適化

Gfarm 1.2 PL2 (gfarm-1.2-4)および OpenLDAP 2.1 以降をご利用で，
config-gfarm でメタデータサーバを初期化した場合は，ほぼ最適な状態になり
ます．

そうではない場合は，

* OpenLDAP 2.1 以降の利用
* slapd の backend db で bdb を指定
* slapd.conf で，loglevel 0 の指定
* DB_CONFIG でキャッシュサイズおよび DB_TXN_NOSYNC の指定

が性能向上に大きく貢献します．最適化にあたり，まず，既存のメタデータを
ダンプし，上記の設定に変更し，リストアしてください．以下，手順を簡単に
示します．（これ等のための管理コマンドを作成しようと思いつつ，まだ作成
していません．すみません．）

＃ ダンプ
# ldapsearch -x -LLL -h ldap.example.com -p 389 -b dc=example,dc=com > dump.ldif

％ -h, -p, -b オプションのパラメータは適宜変更してください．

＃ slapd の停止
# service gfarm-slapd stop

＃ 最適化
(1) slapd.conf の編集（以下を追加あるいは修正）
-----
loglevel 0

database bdb
-----
(2) slapd の directory の作成 (以下は例です)
# mkdir /var/gfarm-ldap

％ slapd.conf の directory で指定している directory です．

(3) /var/gfarm-ldap/DB_CONFIG の作成
-----
set_cachesize 0 536870912 2
set_flags DB_TXN_NOSYNC
-----
％ 512 MB を指定する場合です．

＃ リストア
# slapadd -f /etc/gfarm-ldap/slapd.conf -l dump.ldif

＃ slapd の起動
# service gfarm-slapd start

2. gfarm_agent の利用

gfarm_agent はメタデータのキャッシュサーバで，二度目のアクセスよりアク
セスが高速になります．(GfarmFS-FUSE をご利用の場合は必要ありません．)

自動的に起動する方法は Gfarm-FAQ.ja の性能チューニングの項に記述してい
ます．

=====
上記によりある程度，以下の 1., 2. の速度が改善されるはずです．
（ただ，次期バージョンでは，さららる速度改善を予定しています．）

また，ファイル配置の比率に関してですが，これは現バージョンのスケジュー
リングアルゴリズムの問題です．gfhost -M ではじめの方に登録されているホ
ストが優先的に割り当てられてしまいます．本件は，いくつかの対応を検討し
ているところです．

建部＠産総研

>> On Sat, 17 Sep 2005 16:53:58 +0900, Matsuo Akihiro <matsuo@xxxxxxxxxxxx> said:

>> こんにちは、ドワンゴの松尾壮紘です
>> 先日のワークショップはお疲れ様でした
>> 席が少し足りないくらいの大盛況で苦労されたと思いますが、
>> 盛り上がってよかったです。

>> 今後の開発方針や、新機能追加スケジュール等が聞け
>> また、懇談会では開発者の方々や 
>> grid ストレージに同じように興味をもつ方々と直接話ができ
>> とても有意義な参加になったと思っています。


>> 私は懇談会でお話したとおり、
>> 現在、gfarm による grid ストレージの速度調査を行っています
>> ----------------------------------------
>> メタサーバ       1 台
>> ファイルノード   3 台
>> 負荷クライアント 3 台
>> ----------------------------------------
>> の構成で gfarm 環境を構築しています。


>> サイズの大きな１ファイルを転送した場合は、
>> NFS よりも速く良好な結果が出ているのですが、
>> 細かいファイルを大量にコピーした場合、
>> 思ったより性能が出ず困っています。


>> これは、gfarm の問題というより、
>> ldap の問題かな？と思っています



>> １．細かいファイルのコピーが遅い 
>> ---
>> 負荷試験で、
>> テスト用データファイル 1KB 前後を 30万ファイル用意し、
>> 負荷クライアントから fuse を使って gfarm にファイルコピーを開始しました

>> # cp -a testfile/ /tmp/fuse/root/   
>> (testfile 以下でさらにディレクトリが分かれ 23000x13ディレクトリ )

>> 夜22時から始めて、翌日12時の段階で 31500 ファイル( 14 時間経過)
>> 3 ノードのファイル配分が以下のようになっていました
>> -----------------
>> filenode01  3000
>> filenode02  8500
>> filenode03 20000
>> -----------------

>> このままファイルコピーが終わるまで(推定120時間) 待てなかったので
>> ここで一旦中断して、
>> meta サーバの HyperThread を ON にして、(マシン再起動含む)
>> 同じファイルコピーをやってみましたが、
>> 15分で 500 ファイルと (2000ファイル/時) あまり変わらない速度でした。
>> この時のファイル配置比率は 10:150:330


>> ２．ファイルが大量に置かれると遅くなる
>> ---
>> また、
>> umount 
>> gfarmfs /tmp/fuse/
>> ls /tmp/fuse/root/
>> すると、
>> 応答が返ってくるまで、230 秒かかる。
>> ---------------------------------------------
>> # umount /tmp/fuse/
>> # gfarmfs /tmp/fuse/
>> # time -p ls /tmp/fuse/root
>> file2  hoge  hogefile3  install.log  testfile
>> real 229.08
>> ---------------------------------------------
>> その間 meta サーバ上で slapd が CPU を5〜20% 使って動作している

>> 以後、ls の結果は瞬時に返って来るようになるが、
>> umount gfarmfs をやり直すと、
>> また ls に時間がかかるようになる。

>> これはファイル数が増えるにつれて、時間がかかる物なのか？

>> ls の結果 (メタ情報)は
>> 毎回 meta が返しているわけではなく、
>> クライアント側にキャッシュしている？ 
>> (その為初回に全部のメタ情報を読み込み結果を渡している？)


>> 現時点での懸案点は、
>> -----------------------------------------------------------------------
>> ・ファイル配置比率が 1:3:7 なのが気になる
>>   3 台のファイルノードはハード、OS のスペックは一緒
>>   ディスクの空き容量が違っていたので、それが理由かも？
>>   (filenode01 が元からディスクの空き容量が少なかった)

>> ・gfarm の性能を上げようとするとき、
>>   ボトルネックがどこにあるのか掴めていない
>>   meta と filenode の CPU MEM HDD eth を見ていたが、
>>   filenode にはかなり余裕がある
>>   meta のメモリを増設と、HDD 速度を上げたほうがいいかもしれない

>> ・meta サーバのファイルコピー直後の slapd のメモリ消費量は
>>   313 MB だったが、再起動後は 81MBしか使用していない
>>   gfarm 上のファイルメタ情報を持っているとしたら、
>>   再起動前、後で減った 230MB に入っていたのは何？
>> -----------------------------------------------------------------------

>> --- 環境
>> OS  FedoraCore3
>> CPU P4-2.8GHz   (HT off)
>> MEM 512MB
>> HDD IDE 1台 (7200rpm)
>> LAN 1000 BASE/T

>> gfarm 1.2.1

>> --- ログ
>> ファイルコピー中の 
>> meta サーバの top 結果 (14時間経過後 再起動前)
>> ------------------------------------------------------------------------
>> top - 16:16:57 up 1 day, 20:16,  4 users,load average: 1.83, 1.51, 1.26
>> Tasks:  70 total,   3 running,  67 sleeping,   0 stopped,   0 zombie
>> Cpu(s):  6.6% us, 4.0% sy, 0.0% ni,71.2% id,17.9% wa,  0.3% hi,  0.0% si
>> Mem:    482296k total,   476588k used,     5708k free,   37132k buffers
>> Swap:  2096472k total,      168k used,  2096304k free,   154352k cached

>>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>>  6225 root      18   0  313m 231m 3168 S  6.3 49.1  43:27.84 slapd
>> 20179 root      15   0  9520 6452 2040 S  1.3  1.3   0:24.98 gfarmfs


>> meta サーバの vmstat の結果
>> ------------------------------------------------------------------------
>> procs --------memory-------- ---swap-- -----io---- --system-- ----cpu--
>>  r  b swpd free  buff  cache si   so    bi    bo   in    cs us sy id wa
>>  0  0  192 7972 33628 202192  0    0     0  7807 2504  5936  4  3 85 8
>>  0  0  192 7476 33632 202708  0    0     0  7930 2528  5920  4  3 87 6
>>  1  0  192 6980 33632 203228  0    0     1  7668 2481  5639  4  2 84 9
>>  0  0  192 6484 33632 203748  0    0     1  7764 2496  5723  4  2 87 7


>> meta サーバの
>> CPU に余裕はある
>> ディスク書き込みが非常に多い
>> SWAP は使っていない
>> ここにはないが eth は余裕がある


>> 次回には
>> もっとまとまったデータをレポートできると思います。

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