首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Distributions
Ubuntu
Fedora
CentOS
中文资源站
网易开源镜像站
宝塔
V2EX  ›  Linux

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

  •  
  •   wuxqing · 2015-04-20 17:33:29 +08:00 · 3119 次点击
    这是一个创建于 1670 天前的主题,其中的信息可能已经有所发展或是发生改变。
    有个大分区,下面有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类型
    22 回复  |  直到 2015-04-24 20:55:42 +08:00
        1
    Tiande   2015-04-21 14:27:02 +08:00
    找 @Livid 把你移到 /go/linux 下吧。
    都过去21h了竟然没人搭理你-。-
        2
    Livid   V2EX Moderator   2015-04-21 14:41:18 +08:00
    海量小文件就是这样的。

    最好的解决方法是换 SSD。
        3
    wuxqing   2015-04-21 14:59:45 +08:00
    @Livid
    不是小文件。每个文件在100M-1G之间
    总共80TB,上SSD成本太大了

    是不是说,真么多文件,必然出现有时文件读取>1s的情况?
        4
    Livid   V2EX Moderator   2015-04-21 15:02:43 +08:00
    你的测试方式是,每次随机读取 20KB,那也就是小文件的场景了。
        5
    9hills   2015-04-21 15:06:48 +08:00 via iPhone
    @wuxqing 你只读20KB,不就是小文件随机读么
        6
    wuxqing   2015-04-21 15:23:17 +08:00
    明白了
    除了换SSD,还有改善方法吗?

    比如:
    换支持小文件更好的文件系统?
    linux参数优化?
        7
    quix   2015-04-21 15:26:41 +08:00
    提供一个思路... 类似于 mac 的 fusion drive ,拷贝热数据到速度较高的 ssd 作为缓存, 80T 的话感觉最少也得准备2TB 的 ssd
        8
    huigeer   2015-04-21 15:36:04 +08:00
    能做到 80T的话, 应该不差上ssd的钱
        9
    missdeer   2015-04-21 15:44:34 +08:00
    上数据库,像那些图床那样
        10
    Andiry   2015-04-21 16:03:03 +08:00
    不说清楚,怎么知道问题出在哪里
    1s以上的情况占多少百分比?是均匀出现还是集中出现?跟文件所在位置有没有关系?
    目录深度平均是多少?耗时主要是出现在open还是read?是第一次访问出现还是多次访问出现?

    这种问题自己加个timing测一下就知道了
        11
    fxxkgw   2015-04-21 16:45:11 +08:00
    @wuxqing 淘宝的tfs 还有ceph对小文件支持的都比较好,而且淘宝自身图片基本都用tfs
        12
    fxxkgw   2015-04-21 16:46:21 +08:00
    而且这么大的数量 问什么不用分布式文件系统呢?
        13
    wuxqing   2015-04-21 17:19:09 +08:00
    @Andiry
    在一个小时的测试中(大约10万次),1s以上的仅2-3次
    不均匀出现,与文件位置无关
    目录2层
    耗时在read,仅open非常快(<1ms)
    不是第一次出现,什么时候出现是未知的,也不是固定的文件

    我已经timing测了很多次了,找不出规律
        14
    wuxqing   2015-04-21 17:28:00 +08:00
    @fxxkgw
    我这个系统类似tfs,把20k的小图片按规则打包成100M-1G的大文件,元数据放redis中
    当初调研时ceph貌似不稳定

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

    大多数情况下读取一个小图片<20ms,能满足需求
    偶尔出现读取一个小图片>1s,甚至>2s
        15
    ryd994   2015-04-21 19:28:14 +08:00 via Android
    block scheduler 换 deadline怎么样?
        16
    Andiry   2015-04-22 00:30:14 +08:00
    @wuxqing 底层的timing测过没有呢?耗时是在FS层还是block层?
    如果是在block层也没有什么好办法了,只能换scheduler试试
        17
    henglinli   2015-04-22 10:22:58 +08:00 via iPhone
    libaio
        18
    wuxqing   2015-04-24 10:06:41 +08:00
    @ryd994
    scheduler 换成deadline,更差了,noop、anticipatoy都测了,还是cfq更好

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

    还做了xfs mount的优化,nobarrier, noatime, nodiratime 没啥改善
    xfs分区对齐没去测试,有数据了,不能乱动
        19
    ryd994   2015-04-24 12:11:09 +08:00 via Android
    @wuxqing 那估计问题就不在这里,deadline一般是满有效的,你参数怎么设置的?
    2秒也真是突破天际了……
    noop和anticipatary当然不行,因为cfg就是为了代替anticipatary的
    另外卡的时侯IOPS高么?
    你这样也许适合dmcache
        20
    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是什么时候提交的了
        21
    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
        22
    ryd994   2015-04-24 20:55:42 +08:00 via Android
    @wuxqing 试试在sysfs里减小read_expire
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   849 人在线   最高记录 5043   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 24ms · UTC 20:40 · PVG 04:40 · LAX 12:40 · JFK 15:40
    ♥ Do have faith in what you're doing.