4个关于fastDFS的大数据量下性能的问题
本帖最后由 workyixin 于 2014-02-14 16:01 编辑大家好,我有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 于 2014-02-14 16:30 编辑
四、部署方式和存储方式
部署方式:
作者推荐采用多个storage服务器(多个group),各自分别挂载几个单盘的方式,以期提高总的磁盘IO性能。
可是,公司硬件资源有限,不能提供那么多的storage服务器。
所以当前,文件不是存储在单盘上,而是只有1个storage服务器,挂载上数十T的EMC厂商的存储设备。
这种方式,是不是不太好?
存储方式:
经测试,缩略图如果打算使用合并存储,就没法以“从文件模式”上传(可以指定文件后缀名)了。
所以当前,没有开启合并存储的功能。
从文件定位的性能考虑,3亿个文件,是不是应该用“合并存储”了?
---作者注:
经与公司运维人员沟通,专业的EMC存储,不同于传统的RAID0~5等磁盘阵列概念,其性能很优,基本不用担心磁盘IO吞吐量和inode分配的问题。
所以目前的部署方式和存储方式,估计是可行的。
存在同样的场景,关注。。。。 相关问题和测试结论,已经在主帖中回复说明了,欢迎大家补充更多的意见!
另外,测试中,1亿数据量时,观察fastDFS的binlog日志文件的情况如下:
storage/data/sync目录下,产生了7个binlog.00~文件,共计约7G大小。
由于采用合并存储,storage/data/trunk目录下,还有1个binlog文件,大小15.68G,其中记录了(可能是)每个trunk文件内的详细信息。 本帖最后由 allnew 于 2014-02-26 13:28 编辑
问一个问题:长时间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。
allnew:
问题1:上传过程,应该是client读文件,把文件流通过socket发送给storage,storage写文件。
所以猜测你lsof命令发现的storage进程可能正在写文件,是否由于文件尚未传输接收完全,因此低于原始大小。
不太清楚还有哪些地方可以检查。如果你用本机client上传,能调试跟踪就好了。
问题2:目前,没有相应的配置可以使storage不产生binlog。单机部署的情况下的确用不上binlog,也许可以修改源代码注释掉。 回复 1# workyixin
好信息哦,有机会测试下。
回复 6# workyixin
关于问题1,我看你的程序也是用Java写的,编写Client有什么特别需要注意的吗,我就是参照Java Client API的test代码进行编写的。 回复 8# allnew
java客户端也没什么特殊的地方,只需注意最后调用trackerServer.close()及时关闭连接,否则服务端会容易超过max_connections,造成客户端抛出recv package size -1 != 10或者Connection reset异常,无法再继续上传。
workyixin 发表于 2014-03-11 10:41 static/image/common/back.gif
回复 8# allnew
java客户端也没什么特殊的地方,只需注意最后调用trackerServer.close()及时关闭连 ...
谢谢,我回去再试一下