有个大分区，下面有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类型
找 把你移到 /go/linux 下吧。
都过去21h了竟然没人搭理你-。-

海量小文件就是这样的。
最好的解决方法是换 SSD。


不是小文件。每个文件在100M-1G之间
总共80TB，上SSD成本太大了
是不是说，真么多文件，必然出现有时文件读取>1s的情况？

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

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

明白了
除了换SSD，还有改善方法吗？
比如：
换支持小文件更好的文件系统？
linux参数优化？

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

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

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

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

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

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


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


我这个系统类似tfs，把20k的小图片按规则打包成100M-1G的大文件，元数据放redis中
当初调研时ceph貌似不稳定
现在这个系统就是分布式的（简单），只不过单个节点有80TB（现在想想硬件弄小点）
大多数情况下读取一个小图片<20ms，能满足需求
偶尔出现读取一个小图片>1s，甚至>2s

block scheduler 换 deadline怎么样？

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

libaio


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

底层的timing测过如何做，这块我很菜，望能赐教，非常感谢！
还做了xfs mount的优化，nobarrier, noatime, nodiratime 没啥改善
xfs分区对齐没去测试，有数据了，不能乱动

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

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


配置deadline
echo deadline > /sys/block/{devname}/queue/scheduler
也尝试了在grub中配置
iops没记录，不清楚卡的时候高不高。 回头测一下
服务器用fio测试20k的块，40线程iops能到3000
我的测试程序是单进程的，测试时iops才80

试试在sysfs里减小read_expire