腾讯免费企业邮箱很垃圾的，内部发个通告经常提示发信到上限了，实际上才发送10多封（管理端日志可以看到全部账户累计才10多封），而且第二天不会清零。给发了邮件、留了言。除了收到一份自动的产生的邮件，没任何反馈，也不给解决问题
楼主还是换别的吧

可以先用能连上docker 官方镜像的机子下载镜像
docker pull xxx镜像

然后保存为文件
docker save -o xxx.tar xxx镜像

在内网机子上导入
docker load -i xxx.tar

建议内网架设docker私服

会red hat 7.3，装fedora21吧。命令啥的一样

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

也尝试了在grub中配置

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

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

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

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

桌面系统，一些数据/文档是在/home/用户/下面
有些软件也是安装在/home/用户/下面的，比如gitlab

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

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

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

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

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

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

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

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

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

谁能帮助分析下原因
https://www.v2ex.com/t/185005

只有8g内存, 有点少

也有可能是甲亢，最好去医院看下

我记得重构的时候，会出现preview的选择界面，可以选哪些目录要重构

你重构的时候可以选择源代码的目录

按理说应该慢在文件读入内存的地方。内存扫一遍应该很快的，5G的内存扫一遍应该不超过1s

5G的文件，肯定要扫一边的。只能在统计的地方优化。

stat = char[256]

内存1 = 读取1000MB数据； 看机器的内存，可以分配大点，比如1000M
扫描 内存1 的每个字节
stat[字节值] += 1