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

V2EX = way to explore

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

现在注册

已注册用户请登录

Distributions

› Ubuntu

› Fedora

› CentOS

中文资源站

› 网易开源镜像站

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

有个大分区，下面有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类型

读取

9260-8i

20ms

22 条回复 • 2015-04-24 20:55:42 +08:00

Tiande

2015-04-21 14:27:02 +08:00

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

Livid

MOD

2015-04-21 14:41:18 +08:00

海量小文件就是这样的。

最好的解决方法是换 SSD。

wuxqing

2015-04-21 14:59:45 +08:00

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

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

Livid

MOD

2015-04-21 15:02:43 +08:00

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

9hills

2015-04-21 15:06:48 +08:00 via iPhone

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

wuxqing

2015-04-21 15:23:17 +08:00

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

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

quix

2015-04-21 15:26:41 +08:00

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

huigeer

2015-04-21 15:36:04 +08:00

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

missdeer

2015-04-21 15:44:34 +08:00

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

Andiry

2015-04-21 16:03:03 +08:00

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

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

fxxkgw

2015-04-21 16:45:11 +08:00

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

fxxkgw

2015-04-21 16:46:21 +08:00

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

wuxqing

2015-04-21 17:19:09 +08:00

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

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

wuxqing

2015-04-21 17:28:00 +08:00

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

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

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

ryd994

2015-04-21 19:28:14 +08:00 via Android

block scheduler 换 deadline怎么样？

Andiry

2015-04-22 00:30:14 +08:00

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

henglinli

2015-04-22 10:22:58 +08:00 via iPhone

libaio

wuxqing

2015-04-24 10:06:41 +08:00

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

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

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

ryd994

2015-04-24 12:11:09 +08:00 via Android

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

Andiry

2015-04-24 12:56:10 +08:00

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

wuxqing

2015-04-24 15:45:49 +08:00

@ryd994
配置deadline
echo deadline > /sys/block/{devname}/queue/scheduler

也尝试了在grub中配置

iops没记录，不清楚卡的时候高不高。回头测一下
服务器用fio测试20k的块，40线程iops能到3000
我的测试程序是单进程的，测试时iops才80

ryd994

2015-04-24 20:55:42 +08:00 via Android

@wuxqing 试试在sysfs里减小read_expire