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=0和data=writeback.

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

IO调度器电梯

另一种可能是交换 IO 电梯；请参阅Documentation/block/switching-sched.txtLinux 内核源代码树。简短版本是 、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 团队有更长的启动延迟，并希望内核可以做出一些努力来改善他们的启动时间。内核团队一直建议使用更少、更大的文件方法。

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