4个关于fastDFS的大数据量下性能的问题

workyixin

大家好，我有4个关于fastDFS的大数据量下性能的问题，希望得到全部or部分的解答，谢谢！

一、fastDFS在大数据量(存储>3亿张图片文件)时，会不会出现性能瓶颈(上传和http浏览)？
        ---我个人猜测不会，但没有在论坛上找到明确的回答。
                binlog文件中记录了所有存储文件的信息，每个binlog文件最大1G。
                不过binlog似乎只是用于组内的文件同步复制，并不用于检索？
           所以猜测，并发上传时，binlog会增加记录，但在“大数据量下”，并不会产生明显的性能问题？
                     并发浏览时，nginx通过link(或者解析文件名之后)直接转到相应文件，没有binlog或任何文件的检索，所以也无性能问题？
        ---作者注：               
                测试说明：
                    测试环境: DFS单台虚拟服务器8核CPU,16G内存。  大图平均400K，小图平均14K。
                    利用合并存储，通过约40小时的持续上传1Byte文件，制造了1亿数据量。

               测试结果：
                   上传速度：           DFS已存储数据量          0                     8000万          8000万
                                                               类型          普通上传         普通上传        合并存储上传
                                 耗时(10万大图10万小图)              101分钟         101分钟         96分钟
   
                   读取速度：           DFS已存储数据量          20万            1亿             1亿
                                                               类型          普通读取         普通读取        合并存储读取
                        平均耗时(50并发，各同时8张小图)              0.092(秒)           0.092
                      平均耗时(100并发，各同时8张小图)              0.175                0.176
                        平均耗时(50并发，各同时8张大图)              1.207                1.215              1.219
                      平均耗时(100并发，各同时8张大图)              2.313                2.345              2.348
               测试结论：
                  1、DFS没有性能瓶颈的问题，上传和浏览时，不用传统的类似DB检索的过程，所以速度稳定可靠。
                  2、如果开启合并存储，上传和读取的速度，与普通存储差不多，可以放心使用。

二、由于上个疑问，现在想制造>1亿的海量数据，然后进行(上传和http浏览的)性能测试。
    我的做法是利用"合并存储"功能，持续上传最小的1byte的文件。经测试，平均3ms可以上传1个，预计3.75天可上传1.08亿。
    可是，每次上传到3966个左右，就会报错java.net.BindException: Address already in use: connect，等约150秒后才能继续上传。
    我尽量调整大了max_connections和work_threads设置，也修改过sysctl.conf配置，可还是不起半点作用，每次上传到3966个左右仍会报这个错。
    这个错误不解决，我制造1亿数据，耗费的总时间就得增加10倍。
   
    ---作者注：该问题已解决。
               原因是我之前只优化了DFS服务器的linux相关参数，但是上传代码是在我的winXP本机执行的，connect错误发生在我的电脑上。
               后来把上传代码移至另一台同样优化过的linux服务器上执行，持续上传再也没有中断。

三、fastDHT会对fastDFS起什么作用？除了"可用于存储文件别名、可以文件排重"，有没有别的作用，对于DFS性能有没有帮助？
   
    ---作者注：如题，DHT对于DFS，应该主要是这两个作用，与DFS性能没有关系。

workyixin

四、部署方式和存储方式
    部署方式：
        作者推荐采用多个storage服务器(多个group)，各自分别挂载几个单盘的方式，以期提高总的磁盘IO性能。
        可是，公司硬件资源有限，不能提供那么多的storage服务器。
        所以当前，文件不是存储在单盘上，而是只有1个storage服务器，挂载上数十T的EMC厂商的存储设备。
        这种方式，是不是不太好？
    存储方式：
        经测试，缩略图如果打算使用合并存储，就没法以“从文件模式”上传(可以指定文件后缀名)了。
        所以当前，没有开启合并存储的功能。
        从文件定位的性能考虑，3亿个文件，是不是应该用“合并存储”了?
      
      ---作者注：
           经与公司运维人员沟通，专业的EMC存储，不同于传统的RAID0~5等磁盘阵列概念，其性能很优，基本不用担心磁盘IO吞吐量和inode分配的问题。
           所以目前的部署方式和存储方式，估计是可行的。

                       

ljyy1112

存在同样的场景，关注。。。。

workyixin

相关问题和测试结论，已经在主帖中回复说明了，欢迎大家补充更多的意见！

另外，测试中，1亿数据量时，观察fastDFS的binlog日志文件的情况如下：
    storage/data/sync目录下，产生了7个binlog.00~文件，共计约7G大小。
    由于采用合并存储，storage/data/trunk目录下，还有1个binlog文件，大小15.68G，其中记录了(可能是)每个trunk文件内的详细信息。

allnew

问一个问题：长时间Java Client卡住，请问从哪里入手排查。 我也正在建立一个亿级的测试环境

FastDFS 的tracker和storage端配置 除了IP和启用trunk外，均保持默认。V5.x和4.08测试过都有这个问题，

Server：RHEL 6.2 64位，tracker和storage部署在同一台机器上
Client程序也部署在同一台机器上，采用Java编写，调用 1.24 API的upload(group_name, local_path, extname, meta_list)这个方法, meta_list为null。


方法：一个client进程、几十个文件循环反复进行upload，上传的文件有100K的、几十M，都试过。
现象：上传经过大概20分钟后，upload方法卡住。此时，storage和tracker的日志文件中均无明显异常。
         但lsof命令可以发现storage进程正打开一个数据文件，该文件就是前正在上传的文件，但是该文件的大小 低于 原始文件的大小。（为了验证这种情况，选择60M以上的文件超过trunk合并的文件大小上限值）

猜测：1.storage申请磁盘空间hang住
        2.storage没有获取到正确的上传文件的大小

还有哪些地方可以检查的吗，系统日志、或是其它地方。

========
另有一个问题：如何配置使storage不产生同步用的binlog。

workyixin

allnew:
问题1：上传过程，应该是client读文件，把文件流通过socket发送给storage，storage写文件。
        所以猜测你lsof命令发现的storage进程可能正在写文件，是否由于文件尚未传输接收完全，因此低于原始大小。
        不太清楚还有哪些地方可以检查。如果你用本机client上传，能调试跟踪就好了。
问题2：目前，没有相应的配置可以使storage不产生binlog。单机部署的情况下的确用不上binlog，也许可以修改源代码注释掉。

myhome1998

回复 1# workyixin
好信息哦，有机会测试下。


   

allnew

回复 6# workyixin


    关于问题1，我看你的程序也是用Java写的，编写Client有什么特别需要注意的吗，我就是参照Java Client API的test代码进行编写的。

workyixin

回复 8# allnew

    java客户端也没什么特殊的地方，只需注意最后调用trackerServer.close()及时关闭连接，否则服务端会容易超过max_connections，造成客户端抛出recv package size -1 != 10或者Connection reset异常，无法再继续上传。
   

allnew

workyixin 发表于 2014-03-11 10:41
回复 8# allnew

    java客户端也没什么特殊的地方，只需注意最后调用trackerServer.close()及时关闭连 ...

谢谢，我回去再试一下