 |
2
Livid MOD PRO 海量小文件就是这样的。
最好的解决方法是换 SSD。 |
|
4
Livid MOD PRO 你的测试方式是，每次随机读取 20KB，那也就是小文件的场景了。
|
 |
6
wuxqing OP 明白了
除了换SSD，还有改善方法吗？ 比如： 换支持小文件更好的文件系统？ linux参数优化？ |
 |
7
quix Apr 21, 2015
提供一个思路... 类似于 mac 的 fusion drive ,拷贝热数据到速度较高的 ssd 作为缓存, 80T 的话感觉最少也得准备2TB 的 ssd
|
 |
8
huigeer Apr 21, 2015
能做到 80T的话， 应该不差上ssd的钱
|
 |
9
missdeer Apr 21, 2015
上数据库，像那些图床那样
|
 |
10
Andiry Apr 21, 2015
不说清楚，怎么知道问题出在哪里
1s以上的情况占多少百分比？是均匀出现还是集中出现？跟文件所在位置有没有关系？ 目录深度平均是多少？耗时主要是出现在open还是read？是第一次访问出现还是多次访问出现？ 这种问题自己加个timing测一下就知道了 |
 |
12
fxxkgw Apr 21, 2015
而且这么大的数量 问什么不用分布式文件系统呢？
|
|
13
wuxqing OP @Andiry
在一个小时的测试中（大约10万次），1s以上的仅2-3次 不均匀出现，与文件位置无关 目录2层 耗时在read，仅open非常快（<1ms） 不是第一次出现，什么时候出现是未知的，也不是固定的文件 我已经timing测了很多次了，找不出规律 |
|
14
wuxqing OP @fxxkgw
我这个系统类似tfs，把20k的小图片按规则打包成100M-1G的大文件，元数据放redis中 当初调研时ceph貌似不稳定 现在这个系统就是分布式的（简单），只不过单个节点有80TB（现在想想硬件弄小点） 大多数情况下读取一个小图片<20ms，能满足需求 偶尔出现读取一个小图片>1s，甚至>2s |
 |
15
ryd994 Apr 21, 2015 via Android
block scheduler 换 deadline怎么样？
|
 |
17
henglinli Apr 22, 2015 via iPhone
libaio
|
|
18
wuxqing OP |
|
19
ryd994 Apr 24, 2015 via Android
@wuxqing 那估计问题就不在这里，deadline一般是满有效的，你参数怎么设置的？
2秒也真是突破天际了…… noop和anticipatary当然不行，因为cfg就是为了代替anticipatary的 另外卡的时侯IOPS高么？ 你这样也许适合dmcache |
|
20
Andiry Apr 24, 2015
@wuxqing 底层的timing和应用层没啥区别，可以用getrawmonotonic或者rdtsc
xfs的readpage方法是xfs_vm_readpage(), 在fs/xfs/xfs_aops.c 如果是这个函数耗时过长，就要到block层去看bio是什么时候提交的了 |
Select Language