VFS之上的缓冲

Question

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

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

我的问题是: 1)我知道已经存在一种缓冲机制(磁盘缓冲)；你认为上面的场景会带来一些改进吗？(设计要复杂得多，实现一个简单的测试用例也不容易)

2)你有什么建议吗?如果我要实现这个，你有什么建议吗？

非常感谢。

Answer 1

你需要做的比这更好

“显然，这种表现是不可接受的”。

具体来说

• 你是如何衡量它的？你有一个精确的，可重复的数字吗？

你的目标是什么？

为了进行优化，你需要两件事--测量它的方法(一个指标)和一个目标(这样你就知道什么时候停止，或者某个特定技术有多有用或多无用)。

如果两者都没有，恐怕你就完蛋了。

Answer 2

这些写操作有多重要？我有三个建议(可以合并)，但其中一个是大量的工作，另一个是不太安全的……

日志记录

我猜你看到了一些糟糕的性能，部分原因是大多数现代Linux文件系统通用的journaling。日志记录会导致在写入文件元数据时将屏障插入IO队列。您可以尝试使用mount(8)选项barrier=0和data=writeback调低安全性(也许还可以调高速度)。

但是，如果发生崩溃，日志可能无法阻止冗长的fsck(8)。而且在修复问题时，fsck(8)有可能最终会丢弃您的数据。一方面，这不是轻而易举的一步，另一方面，在过去，我们在雪地中以async模式运行ext2文件系统，而没有日志，我们喜欢这样做。

IO Scheduler电梯

另一种可能是交换IO电梯；请参阅Linux内核源代码树中的Documentation/block/switching-sched.txt。简而言之，可以使用deadline、noop、as和cfq。cfq是内核的默认设置，也可能是您的系统正在使用的。您可以查看：

$ 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团队有更长的启动延迟，并希望内核可以做出一些努力来改善他们的启动时间。内核团队一直建议使用更少、更大的文件方法。

Answer 3

在你的场景中，创建/重命名一个文件，同步它，在一个目录中有很多文件，以及有很多文件(带有尾部垃圾)都是一些缓慢的操作。然而，为了避免它们，它只会有助于编写较小的文件(例如，写出归档文件、连接文件或类似文件)。我实际上会尝试一种(有限的)并行异步或同步方法。IO调度器和缓存通常都很好。