这几天测试sector遇到的一些问题

yc
2010-03-03
2012-10-08
  • yc

    yc - 2010-03-03

    环境:4台普通pc,redhat el5, 互联带宽100Mbps。
    sector版本:2.0 release 和3.2日checkout的svn
    snapshot,sysinfo见帖子末尾,基本上采用缺省配置,启动方式全部为手工启动;测试时均采用FUSE mount成本地目录。
    2.0 release碰到的问题:
    1. 碰到一次master因为Segment fault退出,没有生成core dump;
    2. master log里边显示曾经有一个slave退出;不过那个节点的slave进程一直还在。

    然后切换到snapshot版本进行测试,也发现一些问题:
    1. slave 杀掉后重启,报slave join rejected. code: -102;只能重启master才能连上;
    2. vi一个几k的txt,第一次经常要等10s左右才能打开;如果退出再执行就很快,看来已经cache到本地;
    3. 用FUSE经常出现某个目录不能操作,只能强制umount;比如一次测试是我test目录下有600多个子目录,每个子目录里有几个文件;我执行rm -Rf test后,等待很长时间(至少一分钟)才返回:

    rm -Rf /root/export/test

    rm: reading directory `/root/export/test': Operation not permitted
    然后有可能这个目录就再也不能正常访问了。

    我看svn上有JNI接口的java client实现,不知道现在是否比较成熟?

    谢谢,

    附上sysinfo打出来的信息:

    ./sysinfo

    Sector System Information:
    Running since Tue Mar 2 17:41:55 2010
    Available Disk Size 344123 MB
    Total File Size 2.618 MB
    Total Number of Files 187
    Total Number of Slave Nodes 4


    MASTER ID IP PORT
    1: 192.168.0.217 6000


    Total number of clusters 2
    Cluster_ID Total_Nodes AvailDisk(MB) FileSize(MB) NetIn(MB) NetOut(MB)
    0: 0 0 0 0 0
    1: 4 344123 4.69893 0 0


    SLAVE_ID IP TS(us) AvailDisk(MB) TotalFile(MB) Mem(MB) CPU(us) NetIn(MB)
    NetOut(MB)
    1: 192.168.0.217 1267582083217379 67653 1.30203 109.98 4530000 0.0048542 0
    2: 192.168.0.216 1267582074283918 141249 0.707703 108.984 1890000 0.0449877
    0.00201893
    3: 192.168.0.218 -1 68012.6 2.07994 0 0 0 0
    4: 192.168.0.215 1267582077371676 67208.2 0.609262 109.184 510000 0.00671864 0

     
  • yc

    yc - 2010-03-03

    刚发现218这个节点看起来有些异常:

    3: 192.168.0.218 -1 68012.6 2.07994 0 0 0 0

    上边提到的master log里边显示slave退出的问题中, 记得也是这个218节点的slave

     
  • Yunhong Gu

    Yunhong Gu - 2010-03-04

    你好,非常感谢你的反馈。

    我刚发布了2.1版本,改正了几个在2.0里会segmentation fault的bug。当你关闭一个slave后,master不会立刻知道这个slave已
    经丢失,所以如果你立即重起同一个slave,master会认为是冲突。大约10分钟以后master会检测到这个丢失的slave。

    目前我们还没有做很多针对小文件的优化,另外fuse本身也有一定的overhead。我会再测试你提到的问题。

    那个JNI接口是针对1.24a的,2.x的接口有些小改动,还没有更新到JNI接口上。

     
  • yc

    yc - 2010-03-05

    谢谢回复。最近又简单做了些write性能测试,下边是初步的一些结果,供参考。(Gluster是raid 1,sector是replica num = 2)
    注:目前我们用的机器是4台普通pc,交换机也是比较烂的100Mbps的,可能对结果有影响。

    测试结果:
    1.大块文件的写:
    命令:dd if=/dev/zero of=./sample-file-1 bs=1M count=128

    Gluster/FUSE: 11.7MB/s
    NFS: 10.2MB/s
    Sector/FUSE: 3.7MB/s

    2.用java程序5个线程并行生成大量4-80k的小文件:
    5 Threads, no sleep
    NFS: 2531 KB/s
    Gluster: 1200KB/s
    Sector/FUSE: 500KB/s - 1300KB/s

    Sector在第二个测试中性能不稳定,一会高一会低,另外还经常报错(应该是FUSE相关的);不过Gluster用FUSE mount相对会比较稳定。

    另外目录浏览、文件操作的感受上,NFS基本跟本地文件差不多,而FUSE mount的Gluster和Sector总是会感受到延迟。

     
  • Yunhong Gu

    Yunhong Gu - 2010-03-09

    Sector的FUSE部分还有很多优化需要做,特别是cache。第一个结果不应该那么差,你有没有试过直接用Sector的upload?

    另外glusterfs和Sector的机制很不一样。glusterfs没有master metadata
    server,所以没有这一步的overhead。但是同时它也不保证多个client之间的一致性。

     
  • yc

    yc - 2010-03-10

    测试了下upload的性能,是比FUSE mount要好很多:

    time ./upload sample-file-1 /

    uploading sample-file-1 of 134217728 bytes
    open file //sample-file-1 192.168.0.216 42946
    Uploading accomplished! AVG speed 88.2327 Mb/s.

    real 0m12.512s
    user 0m0.349s
    sys 0m0.751s

    上传134M花了12.5s,大约10.7MB/s

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks