缓冲在VFS之上

问题描述

| 我尝试解决的问题是保存大量（百万）个通过网络发送的小文件（最大50KB）。保存是按顺序进行的：服务器接收文件或目录（通过网络），然后将其保存在磁盘上；下一个到来，已保存等。 显然，如果多个服务器进程共存（如果我有5个进程都从网络读取并同时写入），则性能是不可接受的，因为I / O调度程序无法有效地合并I / O写入。 建议的解决方案是实现某种缓冲：每个服务器进程应具有50MB的高速缓存，其中应写入当前文件，执行chdir等；当缓冲区已满时，应将其同步到磁盘，从而获得I / O突发。 我对您的问题： 1）我知道已经存在一个缓冲机制（磁盘缓冲区）；您是否认为上述情况会有所改善？ （设计要复杂得多，实现一个简单的测试用例并不容易） 2）您有什么建议，我应该在哪里看？ 非常感谢。     

解决方法

        您将需要做得比 \“显然性能不可接受\”。 特别 您如何测量？你有一个精确的，可复制的数字吗 您的目标是什么？ 为了进行优化，您需要做两件事：一种测量方法（一个指标）和一个目标（这样您就知道何时停止，或特定技术的有用或无用）。 恐怕没有这些，您会沉没。     ,        这些写有多重要？我有3条建议（可以合并），但其中一项建议需要大量工作，其中一项建议的安全性较差... 日志记录 我猜测您看到的性能有些不佳，部分原因是大多数现代Linux文件系统共有日志记录。写入文件元数据时，日志记录会导致将屏障插入IO队列。您可以尝试使用

mount(8)

选项

barrier=0

和

data=writeback

降低安全性（并可能提高速度）。 但是，如果发生崩溃，日志可能无法阻止冗长的

fsck(8)

。解决问题时，ѭ3可能会丢掉您的数据。一方面，这不是轻率的一步，另一方面，回到过去，我们以

async

模式运行

ext2

文件系统，而没有日志，这在雪中都是我们喜欢的。 IO Scheduler电梯 另一种可能性是交换IO电梯；请参阅Linux内核源代码树中的ѭ7。简短的版本是

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开发团队将其地图，纹理，对象等打包为15张巨型文件，通过几次系统调用即可将其读入程序，然后解压缩并运行，因为发现性能要比读取数百或数千个较小的文件好得多。级别之间的加载时间大大缩短。 （b）Gnome桌面团队和KDE桌面团队采用了不同的方式来加载其图标和资源文件：KDE团队将其许多小文件打包为某种较大的文件包，而Gnome团队则没有。 Gnome团队有更长的启动延迟，并希望内核能够做出一些努力以缩短启动时间。内核团队一直在建议使用更少，更大的文件方法。     ,        创建/重命名文件，同步文件，目录中有很多文件以及文件很多（浪费尾巴）是您方案中一些缓慢的操作。但是，要避免它们，只会有助于写入较少的文件（例如，写出归档文件，串联文件或类似文件）。我实际上会尝试（有限的）并行异步或同步方法。 IO调度程序和缓存通常都很好。