内网,windows,有很多子服务器在不停的上传小文件(约 20k-50k )到中心服务器,每台子服务器每秒大约上传 20 个,现在的方案是在中心服务器上开了个共享目录,子服务器挂载了这个共享目录然后直接往这个共享目录里写小文件。小文件的文件名是 uuid 绝对不会重复的。 现在的问题是这种方案性能不好,偶发性的写入文件这个操作大约要耗时几百毫秒有时候甚至 1-2 秒,还有什么更好的方案吗?
1
nightv2 2018-03-05 22:47:07 +08:00 via Android
上传这个逻辑必须是每秒不间断么?要么隔一段时间上传一个压缩包。
|
3
metrxqin 2018-03-05 23:13:07 +08:00 via Android
计算出来每秒数据量,检查子设备跟服务器之间的带宽能不能满足要求。
|
4
wlwood 2018-03-05 23:13:47 +08:00 via Android
其实,我是认为 Windows 不好。(逃…
|
5
yuyuyu OP @metrxqin 内网带宽绝对能满足
也测试了在中心服务器上新挂一块 ssd,新建了一台测试子服务器,写入 ssd 共享目录偶尔还是有几百毫秒到 1、2 秒的耗时 |
6
omph 2018-03-05 23:24:02 +08:00
换传输协议?
要不试试 QUIC |
7
loading 2018-03-05 23:33:18 +08:00 via iPhone
不如试着写到 nosql,内存数据库,没问题。然后再批量写到硬盘。
|
8
crysislinux 2018-03-06 01:30:08 +08:00 via Android
都写到同一个目录了?有没有可能给不同子服务器开不同目录,然后各个目录里按时间再切分,很多文件系统一个目录文件多了就会慢。如果所有机器都挂载同一个目录,一个机器写了数据,就可能需要同步到其他机器,想想要多少操作,不过感觉只要不读目录,应该不会马上同步。。。
|
9
rubycedar 2018-03-06 01:48:26 +08:00 via iPhone
ws 长连接了解一下
|
10
tomczhen 2018-03-06 01:48:55 +08:00 via Android
其实 SSD 不适合这种连续长时间写入,回收时写入会受影响,也许最新的傲腾才可以解决你的问题。
如果场景是日志收集,建议找专门的针对性接近方案处理吧。 |
11
tailf 2018-03-06 10:28:53 +08:00
我觉得压缩一下传输再解压缩是最快的。
|
12
tailf 2018-03-06 10:29:51 +08:00
仔细读了一遍题目,发现理解错了,这种情况确实应该使用 nosql。
|