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

[gfarm-discuss-ja:00085] gfarm 速度調査

こんにちは、ドワンゴの松尾壮紘です


先日のワークショップはお疲れ様でした
席が少し足りないくらいの大盛況で苦労されたと思いますが、
盛り上がってよかったです。

今後の開発方針や、新機能追加スケジュール等が聞け
また、懇談会では開発者の方々や 
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
―――――――――――――――――――――――――――――