优化 RAID5 上 1000-2000 万个文件的存储(目前使用 LVM+XFS)

优化 RAID5 上 1000-2000 万个文件的存储(目前使用 LVM+XFS)

虽然我浏览过这里的一些问题,但我认为每种情况都不同,可能需要完全不同的解决方案。

我现在拥有的:

  • 4x4TB 企业级 HDD 上的 Linux 软件 RAID5
  • 顶部有 LVM 和几个卷
  • 最重要的是存储容量,10TB XFS
  • Debian Wheezy 中的所有设置均使用默认参数
  • 该卷使用选项“noatime、nodiratime、allocsize=2m”安装
  • 我猜大约有 8GB 的​​ RAM 可用,用于缓存,四核 Intel CPU 和 HT 不太常用

此卷主要存储约 1000 万个文件(未来最多 20M),大小在 100K 到 2M 之间。以下是文件大小范围(以 K 为单位)和范围内数字的更精确分布:

       4    6162
       8      32
      32      55
      64   11577
     128    7700
     256    7610
     512     555
    1024    5876
    2048    1841
    4096   12251
    8192    4981
   16384    8255
   32768   20068
   65536   35464
  131072  591115
  262144 3411530
  524288 4818746
 1048576  413779
 2097152   20333
 4194304      72
 8388608      43
16777216      21

这些文件大部分存储在卷的第 7 级,例如:

/volume/data/customer/year/month/day/variant/file

这些文件夹内通常有约 1-2K 个文件,有时更少,有时多达 5-10K(极少数情况)。

I/O 不是那么重,但当我稍微增加一点时,就会出现挂起的情况。例如:

  • 执行最多 I/O 的应用程序是 NGINX,用于读取和写入
  • 总共有一些 1-2MB/s 的随机读取
  • 我有一些文件夹,其中数据以 1-2MB/s 的总速率连续写入,并且所有超过 1 小时的文件应定期从文件夹中删除

每小时运行一次以下 cron 会导致整个服务器多次挂起几秒钟,甚至可能由于生成 I/O 超时而中断服务(写入新数据):

find /volume/data/customer/ -type f -iname "*.ext" -mmin +60 -delete
find /volume/data/customer -type d -empty -delete

我还发现,在写入上述范围内的文件时,写入速度很慢(几 MB/s)。写入较大的文件时,一切正常,直到写入缓存填满(显然如此),然后速度下降并开始使服务器一波一波地挂起。

现在,我正在寻找一种解决方案来优化我的存储性能,因为我确信我的默认设置并不是最佳的,而且很多事情都有待改进。虽然对我来说没什么用,但如果 LVM 不能带来显著的收益,我也不会放弃它,因为虽然可能,但我不会通过放弃 LVM 来重新安装整个服务器。

阅读了很多关于 XFS、ReiserFS 和 Ext4 的比较,但我还是很困惑。我的其他服务器的 RAID1 容量小得多,但设置完全相同,工作负载也大得多,运行起来非常完美。

有任何想法吗?

我应该如何调试/实验?

谢谢。

答案1

首先,对于这种情况,XFS 是正确的选择:使用 XFS 几乎不可能出现 inode 不足的情况。

要提高删除性能,请尝试以下操作:

  • 使用deadlineI/O 调度程序而不是(默认)cfq
  • 用作logbsize=256k,allocsize=64k挂载选项(除了nodiratime,noatime

为了降低删除对其他系统活动的影响,请尝试find使用以下方式运行脚本ionice -c 2 -n 7

报告你的结果!

答案2

同意 Shodanshok 的观点,deadline 可能是一个好主意。但并不确信你应该在这里使用 XFS。

查找/volume/data/customer/-type f-iname“*.ext”-mmin +60-delete

XFS 在删除文件方面曾经表现非常糟糕 —— 有人告诉我,该领域的大多数错误都已解决,但没有进行任何严格的基准测试来证实这一点。

一切正常,直到写入缓存填满(显然),然后速度下降并开始使服务器断断续续地挂起

挂了?听起来你应该调整你的脏页比率(减少背景比率,增加阻塞比率),你还应该更改 dirty_expire_centisecs(增加或减少 - 看看什么使它更快!)并且如果总体负载和 CPU 使用率是可以接受的,则减少 dirty_writeback_centisecs。

如果“find”语句正在处理大量数据,那么调整 vfs_cache_pressure 是一个好主意。同样,找出正确值的唯一方法是反复试验,但如果扇出率很高,并且可能不读取大量数据文件,那么降低它应该可以提高缓存效率。

请注意,LVM 快照将影响 IO 吞吐量。

---- 无论您选择哪种文件系统,上述内容均适用 ----

选择文件系统时最重要的考虑因素是您需要它有多强大。如果这些都是临时文件,并且您不介意在发生中断时丢失它们/不需要在中断后快速恢复,那么您根本不应该使用日志文件系统。但您没有告诉我们太多有关数据的信息。

注意到高扇出率……ext3/4 的 dir_index 功能被明确添加,以便在目录包含大量文件/文件周转率高时提供更快、更高效的解析。我不知道 XFS 在这种情况下有多有效。

ReiserFS 不再得到很好的支持。

你可能还想看看其他一些东西(包括 UPS、bcache、专用日志设备),但我没有理由推销一本有关该主题的书

相关内容