密集随机 I/O 的文件系统/选项

let*_*eto 3 linux filesystems tuning performance-tuning

我计划(私下)部署一个服务器,该服务器将在 100MB 到 50GB 的文件中使用随机 I/O。请求的范围从 128 KB 到 4MB。配置文件将是 50:50,涉及读取和写入,并有更多读取的趋势。

什么文件系统可以最好地处理这种负载?我现在选择了 XFS。但是我应该研究哪些可调参数?

谢谢

sys*_*138 6

要求和限制:

  • 50:50 读写比率
  • 正在写入的文件的范围从远大于块大小到远大于块大小。
  • 单个请求的范围从 128KB 到 4MB
  • 在 Linux 上
  • 文件系统将非常大,为 14TB。

有帮助的未知数:

  1. 随机 I/O 是否在文件内,或者纯粹基于以 128KB-4MB 块读取和写入的整个文件
  2. 文件更新的频率。
  3. 并发:并行读/写操作(I/O 操作)的频率。

顺序输入/输出

如果 50:50 的比例是通过读取和写入整个文件以及相当大的文件来表示的,那么就文件系统而言,您的访问模式比随机更连续。使用基于盘区的文件系统来增加文件系统的顺序性以获得最佳性能。由于文件太大,如果硬件支持,预读将显着提高性能(某些 RAID 控制器提供此功能)。


随机输入/输出

如果您计划同时进行读/写活动,这种情况会发生变化,此时它确实变得非常随机。如果您打开大量文件并在这些文件中读取/写入小部分,这同样适用,就好像它是一个数据库一样。

我遇到的最大误解之一是,在处理高度随机的 I/O 时,碎片整理的文件系统比碎片化的文件系统性能更好。这仅适用于元数据操作在碎片文件系统上受到很大影响的文件系统中。对于非常高级别的碎片,基于盘区的文件系统实际上比其他类型的块管理会遭受更多的性能下降。

也就是说,只有当 I/O 访问模式和速率将磁盘推到最大容量时,这个问题才会变得明显。文件系统中有 14TB,这意味着实际存储阵列中有 7 到 50 个心轴,从而产生了广泛的功能;从 7x 2TB 7.2K RPM 驱动器的 630 I/O Ops 到 50x 300GB 15K RPM 驱动器的 9000 I/O Ops。7.2K RPM RAID 阵列达到 I/O 饱和的速度比 15K RPM RAID 阵列快得多。

如果您的 I/O 操作率没有推动您的存储限制,那么文件系统的选择应该更多地基于整体管理灵活性,而不是调整最后几个百分点的性能。


但是,如果您的 I/O 确实在完全运行您的存储,那么这就是开始需要调整的时候。

XFS:

  • 安装:将 'allocsize' 设置为不大于 65536 (64MB),但一定要设置高。这提高了文件访问的元数据速度。
  • 安装:将“sunit”设置为 RAID 阵列的条带大小。也可以在格式化时间设置。
  • 安装:将“swidth”设置为 RAID 阵列中的驱动器数量(或 R5 为 N-1,R6 为 N-2)。也可以在格式化时间设置。
  • 格式:如果你真的需要最后一个百分点,把文件系统日志放在一个完全独立的存储设备上 -l logdev=/dev/sdc3

EXT4:

  • 格式:-E stride设置为 RAID 中单个磁盘条带上的块数(512b 或 4K,具体取决于驱动器)。
  • 格式:-E stripe-width在 XFS 中设置为 'swidth'
  • 格式:与 XFS 一样,通过将日志放在一个完全独立的存储设备上,可以挤出最后一个百分点的性能。 -O journal_dev /dev/sdc3/


小智 0

我认为这里真正的问题不仅仅是文件系统,还有文件系统使用的参数设置。可能影响的一件事可能是预读大小。

但是,好吧,我们只讨论名字。除了 XFS 之外,我认为 ext4 也能满足您的需求。最重要的是,我认为您需要基于范围的文件系统来尽可能避免碎片。XFS 和 ext4 都支持延迟写入 IIRC,因此两者都可以帮助您增加进行写入合并的机会。

问候,

穆利亚迪。