【问题标题】:Performance issues in writing to large files?写入大文件时的性能问题?
【发布时间】:2010-09-12 14:54:07
【问题描述】:

我最近参与处理服务器的控制台日志,出于好奇,我想知道,与小文件相比,写入大文件是否存在性能问题。

例如,保持日志文件较小而不是让它们变得庞大是一个好主意,但我无法为这两种方法提供太多支持。

在文件中读取或搜索可能会出现问题,但现在我更想知道写入是否会受到任何影响。 寻求专家建议。

编辑: 我认为操作系统只需要打开一个文件句柄并将数据推送到文件系统。与文件大小几乎没有相关性,因为您必须继续将数据附加到文件的末尾,并且每当数据块已满时,操作系统都会为文件分配另一个块。前面说了,由于文件块的碎片整理,在读取和搜索时可能会出现问题,但我在写入时并没有发现太大的差异。

【问题讨论】:

  • 如果您使用的是 ext 或其他现代 Unix/Linux 文件系统,那么用(附加的)日志文件填充磁盘是唯一会导致文件系统碎片化的用例(如果您在 Microsoft 的 Windows 上,请忽略这一点,几乎每个用例(具有并发或删除)都会导致您的文件系统碎片化)。要减轻这种碎片化,请旋转并压缩您的日志文件(为此使用日志旋转工具)。压缩不仅会减小文件大小,还会对文件进行碎片整理。
  • 可能还有一个更重要的问题:可管理性。虽然写入日志文件很重要,但如何处理存储管理(日志轮换、导出等)几乎是架构中最明显的部分。大多数应用程序以某种大小限制其日志文件或将数据限制在特定时间范围(日/周/等)。这提供了许多较小的文件,您可以比单个文件更优雅地管理它们。

标签: file logging file-io performance


【解决方案1】:

作为一般规则,将块附加到小文件(或写入要附加到零长度文件的第一个块)或将块附加到大文件之间应该没有实际区别。

有一些特殊情况(例如尝试在三间接块中出错或必须读取所有映射信息的初始打开)可能会添加额外的 I/O。但稳态应该是一样的。

我会更担心拥有大文件的可管理性:备份速度慢、复制速度慢、查看速度慢等。

【讨论】:

    【解决方案2】:

    我不是专家,但无论如何我都会尝试回答。

    较大的文件可能需要更长的时间才能写入磁盘,实际上这不是编程问题。是文件系统问题。也许有些文件系统没有这样的问题,但在 Windows 上,大文件不能被写成一个整体,因此将它们分段需要时间(原因很简单,磁头必须移动到其他柱面)。假设我们谈论的是“经典”硬盘......

    如果您需要建议,我会写下较小的文件并每天或在它们达到一定大小时(或两者兼而有之)旋转它们。这是我在企业级产品中看到的相当常见的方法。

    【讨论】:

    • 我认为的方式是操作系统只需要打开一个文件句柄并将数据推送到文件系统。与文件大小几乎没有相关性,因为您必须继续将数据附加到文件末尾,并且每当一个数据块已满时,操作系统就会为该文件分配另一个块。
    猜你喜欢
    • 1970-01-01
    • 2012-11-30
    • 1970-01-01
    • 2022-12-09
    • 2011-07-22
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-09-24
    相关资源
    最近更新 更多