2

我试图解决的问题是保存大量(数百万)小文件(最大 50KB),这些文件是通过网络发送的。保存是按顺序完成的:服务器接收文件或目录(通过网络),将其保存在磁盘上;下一个到了,它被保存了等等。显然,如果多个服务器进程共存(假设我有 5 个进程同时从网络读取和写入),性能是不可接受的,因为 I/O 调度程序没有无法有效地合并 I/O 写入。

一个建议的解决方案是实现某种缓冲:每个服务器进程应该有一个 50MB 的缓存,它应该在其中写入当前文件,执行 chdir 等;当缓冲区已满时,应将其同步到磁盘,从而获得 I/O 突发。

我对你的问题:1)我知道已经存在缓冲机制(磁盘缓冲区);您认为上述情况会增加一些改进吗?(设计要复杂得多,实现一个简单的测试用例并不容易)

2)你有什么建议,如果我会实施这个,在哪里看?

非常感谢。

4

3 回答 3

1

你需要做得比

“显然性能是不可接受的”。

具体来说

  • 你是怎么测量的?你有一个准确的、可重复的数字吗
  • 你的目标是什么?

为了进行优化,您需要两件事 - 测量它的方法(指标)和目标(以便您知道何时停止,或者特定技术的有用或无用)。

没有任何一个,你就会沉没,我害怕。

于 2011-05-31T19:24:53.050 回答
0

创建/重命名文件、同步文件、目录中有大量文件以及有大量文件(带有尾部浪费)是您的场景中的一些缓慢操作。然而,为了避免它们,它只会有助于编写较小的文件(例如写出档案、连接文件或类似文件)。我实际上会尝试(有限的)并行异步或同步方法。IO 调度程序和缓存通常非常好。

于 2014-12-04T02:38:34.123 回答
0

这些文字有多重要?我有三个建议(可以组合),但其中一个工作量很大,其中一个不太安全......

日记

我猜你会看到一些糟糕的性能,部分原因是大多数现代 Linux 文件系统常见的日志。写入文件元数据时,日志会导致屏障插入 IO 队列。您可以尝试使用mount(8)选项barrier=0data=writeback.

但如果发生崩溃,期刊可能无法防止冗长的fsck(8). 在解决问题时,有可能最终fsck(8)会丢弃您的数据。一方面,这不是一个轻率的步骤,另一方面,在过去,我们在没有日志ext2的模式下运行我们的文件系统,async在雪地里双向运行,我们喜欢它。

IO调度器电梯

另一种可能是交换 IO 电梯;请参阅Documentation/block/switching-sched.txtLinux 内核源代码树。简短版本是 、deadlinenoopas可用cfqcfq是内核默认值,可能是您的系统正在使用的。您可以检查:

$ cat /sys/block/sda/queue/scheduler
noop deadline [cfq] 

文件中最重要的部分:

As of the Linux 2.6.10 kernel, it is now possible to change the
IO scheduler for a given block device on the fly (thus making it possible,
for instance, to set the CFQ scheduler for the system default, but
set a specific device to use the deadline or noop schedulers - which
can improve that device's throughput).

To set a specific scheduler, simply do this:

echo SCHEDNAME > /sys/block/DEV/queue/scheduler

where SCHEDNAME is the name of a defined IO scheduler, and DEV is the
device name (hda, hdb, sga, or whatever you happen to have).

The list of defined schedulers can be found by simply doing
a "cat /sys/block/DEV/queue/scheduler" - the list of valid names
will be displayed, with the currently selected scheduler in brackets:

# cat /sys/block/hda/queue/scheduler
noop deadline [cfq]
# echo deadline > /sys/block/hda/queue/scheduler
# cat /sys/block/hda/queue/scheduler
noop [deadline] cfq

更改调度程序可能是值得的,但根据日志要求插入队列的障碍,可能不会有太多的重新排序。不过,丢失数据的可能性较小,因此这可能是第一步。

应用程序更改

另一种可能性是彻底改变您的应用程序以捆绑文件本身,并将更少、更大的文件写入磁盘。我知道这听起来很奇怪,但是 (a) iD 开发团队将他们的地图、纹理、对象等打包成巨大的zip他们会通过几个系统调用将文件读入程序,解压缩并运行,因为他们发现性能比读取几百或几千个小文件要好得多。关卡之间的加载时间大大缩短。(b) Gnome 桌面团队和 KDE 桌面团队采用不同的方法来加载他们的图标和资源文件:KDE 团队将他们的许多小文件打包成某种更大的包,而 Gnome 团队没有。Gnome 团队有更长的启动延迟,并希望内核可以做出一些努力来改善他们的启动时间。内核团队一直建议使用更少、更大的文件方法。

于 2011-05-31T09:53:51.207 回答