linux 下面文件读取效率不稳定，有办法破吗？

[wuxqing]

有个大分区，下面有400万个文件，分散在65536个文件夹下面
单进程随机打开一个文件，读取20KB，连续读取1小时。
测试结果：
大多数（98.5%）是在<20ms
有些会到200ms

很意外的是，尽然有>1s，甚至是2s的
这是啥情况？

测试环境：
OS：CentOS 6.4
CPU：Xeon E5-2600 v2 X2
MEM: 64G
RAID: LSI 9260-8I 6GB 8口 512MB
DISK: SAS 4TB X 24
做了raid 6，分区是xfs类型

[Tiande]

找 @Livid 把你移到 /go/linux 下吧。
都过去21h了竟然没人搭理你-。-

[Livid]

海量小文件就是这样的。

最好的解决方法是换 SSD。

[wuxqing]

@Livid
不是小文件。每个文件在100M-1G之间
总共80TB，上SSD成本太大了

是不是说，真么多文件，必然出现有时文件读取>1s的情况？

[Livid]

你的测试方式是，每次随机读取 20KB，那也就是小文件的场景了。

[9hills]

@wuxqing 你只读20KB，不就是小文件随机读么

[wuxqing]

明白了
除了换SSD，还有改善方法吗？

比如：
换支持小文件更好的文件系统？
linux参数优化？

[quix]

提供一个思路... 类似于 mac 的 fusion drive ,拷贝热数据到速度较高的 ssd 作为缓存, 80T 的话感觉最少也得准备2TB 的 ssd

[huigeer]

能做到 80T的话， 应该不差上ssd的钱

[missdeer]

上数据库，像那些图床那样

[Andiry]

不说清楚，怎么知道问题出在哪里
1s以上的情况占多少百分比？是均匀出现还是集中出现？跟文件所在位置有没有关系？
目录深度平均是多少？耗时主要是出现在open还是read？是第一次访问出现还是多次访问出现？

这种问题自己加个timing测一下就知道了

[fxxkgw]

@wuxqing 淘宝的tfs 还有ceph对小文件支持的都比较好，而且淘宝自身图片基本都用tfs

[fxxkgw]

而且这么大的数量 问什么不用分布式文件系统呢？

[wuxqing]

@Andiry
在一个小时的测试中（大约10万次），1s以上的仅2-3次
不均匀出现，与文件位置无关
目录2层
耗时在read，仅open非常快（<1ms）
不是第一次出现，什么时候出现是未知的，也不是固定的文件

我已经timing测了很多次了，找不出规律

[wuxqing]

@fxxkgw
我这个系统类似tfs，把20k的小图片按规则打包成100M-1G的大文件，元数据放redis中
当初调研时ceph貌似不稳定

现在这个系统就是分布式的（简单），只不过单个节点有80TB（现在想想硬件弄小点）

大多数情况下读取一个小图片<20ms，能满足需求
偶尔出现读取一个小图片>1s，甚至>2s

[ryd994]

block scheduler 换 deadline怎么样？

[Andiry]

@wuxqing 底层的timing测过没有呢？耗时是在FS层还是block层？
如果是在block层也没有什么好办法了，只能换scheduler试试

[henglinli]

libaio

[wuxqing]

@ryd994
scheduler 换成deadline，更差了，noop、anticipatoy都测了，还是cfq更好

@Andiry
底层的timing测过如何做，这块我很菜，望能赐教，非常感谢！

还做了xfs mount的优化，nobarrier, noatime, nodiratime 没啥改善
xfs分区对齐没去测试，有数据了，不能乱动

[ryd994]

@wuxqing 那估计问题就不在这里，deadline一般是满有效的，你参数怎么设置的？
2秒也真是突破天际了……
noop和anticipatary当然不行，因为cfg就是为了代替anticipatary的
另外卡的时侯IOPS高么？
你这样也许适合dmcache

[Andiry]

@wuxqing 底层的timing和应用层没啥区别，可以用getrawmonotonic或者rdtsc
xfs的readpage方法是xfs_vm_readpage(), 在fs/xfs/xfs_aops.c
如果是这个函数耗时过长，就要到block层去看bio是什么时候提交的了