目录中有 500w＋个小文件，有什么办法提高文件系统的性能吗？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

Distributions

› Ubuntu

› Fedora

› CentOS

中文资源站

› 网易开源镜像站

这是一个创建于 3872 天前的主题，其中的信息可能已经有所发展或是发生改变。

无论是 'du -sh /data'或'find /data -type f'都非常慢，使用的是 ext4文件系统。
求推荐优化方法。

优化

系统

21 条回复 • 2014-05-27 13:33:52 +08:00

ysjdx

2014-05-23 17:15:19 +08:00

换reiserfs会不会好点

xdeng

2014-05-23 17:15:44 +08:00

曾经就被这个问题困扰过

pubby

2014-05-23 18:01:22 +08:00

印象中，没有哪个文件系统能吃得消这样整。

你这啥系统，设计方案有问题。

dorentus

2014-05-23 18:04:24 +08:00 via iPhone

du -s 和 find 本来就是要便利文件的，数量多了自然慢
但是你的上层应用应该不会有经常这么做的需求吧

hydrazt

2014-05-23 18:34:00 +08:00

@ysjdx 没尝试过，之后测试一下
@pubby 用户上传的图片，有什么建议吗？吧500w个文件分散倒10000个子目录后，还是慢。。
@dorentus du -s 和 find 只是极端情况

love

2014-05-23 18:49:19 +08:00

我的目录里分了二级目录，比如 xxxxxxxx/xxxxxxxx/xxx.jpg，大概100W左右文件，速度完全没有问题。

当然你说的du -s和find是全遍历，不可能快的，换任何方式存文件都不行。

why

2014-05-23 20:18:13 +08:00

存数据库嘛

20150517

2014-05-23 20:36:56 +08:00

你得用mongo gridfs

micate

2014-05-23 20:52:16 +08:00

嗯，上数据库吧。

或者结构复杂点，比如文件还是散列到目录中，但同时存储一份信息到数据库。
这样可以满足 du -s 的需求，直接数据库 sum()，find 也是数据库记录查找。

xdeng

2014-05-23 22:01:30 +08:00 via iPhone

淘宝的文件系统阿。专处理小文件

cdffh

2014-05-23 23:53:24 +08:00

看看tfs http://code.taobao.org/p/tfs/wiki/deploy/

cuixiaolu

2014-05-24 00:02:16 +08:00

@cdffh 说的，淘宝的TFS应该可以解决这个问题
腾讯的也有TFS，但是不知道有没有开源

skydiver

2014-05-24 00:07:11 +08:00 via Android

按前缀分n级目录就行啊

yakczh

2014-05-24 11:13:26 +08:00

map reduce

7rack

2014-05-24 11:20:08 +08:00

存储最好上SSD，做raid-1哇，如果要备份啥的，要用上 LVM。这里讲的比较多，也许对你有帮助 http://lwn.net/Articles/400629/

perrywky

2014-05-24 13:20:57 +08:00

为何不用又拍云或者七牛

hydrazt

2014-05-24 18:06:27 +08:00

@love @skydiver 目前我们方案也类似 :)
@why @20150571 @micate 数据库的话，会很大，几个t吧。
@xdeng @cdffh tfs有点意思。
@perrywky cdn用于分发文件，本地的存储还是要用的

perrywky

2014-05-24 18:43:13 +08:00

@hydrazt 其实云存储解决的就是这种问题，本地存个索引就行了

hydrazt

2014-05-24 18:48:35 +08:00

@perrywky 自己硬盘上没备份心里不太踏实。不过结合云存储的方案，近期会实践一下，云和本地都存上一份，数据库纪录一下对应关系～

jamiesun

2014-05-25 19:32:58 +08:00

对每个目录在当前创建一个索引文件,使用后台任务进行索引, 查找统计就直接查索引

favormm

2014-05-27 13:33:52 +08:00

数据库吧。