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

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

我现在拥有的:

  • 4x4TB企业硬盘上的Linux软件RAID5
  • LVM上有几卷
  • 最重要的,存储量,一个10TB的XFS
  • 所有在Debian Wheezy中设置的默认参数
  • 卷被安装选项'noatime,nodiratime,allocsize = 2m'
  • 大约8GB的RAM免费和用于caching我猜,四核英特尔CPU与HT不太常用

本卷大多存储在100K到2M之间的大约1000万个文件(将来最多20M)。 这是文件大小范围(以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个文件,有时甚至更less,其他时间最多5-10K(less数情况下)。

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)。 当写入较大的文件时,直到写入caching填充(显然),然后速度下降,并开始挂起服务器波。

现在,我正在寻找一种解决scheme来优化我的存储性能,因为我相信我在默认情况下不是最佳select,而且很多事情都可能得到改善。 虽然对我来说并不是那么有用,但如果它不能提供显着的收益,我也不会放弃LVM,因为虽然可能,但我不会通过删除LVM来重新安装整个服务器。

阅读了很多关于XFS和ReiserFS与Ext4的比较,但是我很困惑。 我的其他服务器的RAID1 2TB体积小得多,但设置完全相同,工作量大得多,性能相当完美。

有任何想法吗?

我应该如何debugging/实验?

谢谢。

首先,如果情况:XFS几乎不可能走出索引节点,那么XFS就是正确的select。

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

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

要降低删除对其他系统活动的影响,请尝试使用ionice -c 2 -n 7来运行find脚本

报告结果!

同意Shodanshok,截止date可能是一个好主意。 远不相信你应该在这里使用XFS。

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

XFS在删除文件方面曾经非常糟糕 – 我被告知这个领域的大多数bug已经被解决了,但是没有做任何硬性的基准testing来证实这一点。

它会一直运行,直到写入caching填满(显然),然后速度下降,并开始挂起服务器波

挂? 听起来像你应该调整你的脏页面比率(减less背景raio,增加阻塞率),你也应该改变dirty_expire_centisecs(上或下 – 看看是什么让它更快!),并减lessdirty_writeback_centisecs总负载和CPU使用率是可以接受的。

如果'find'语句正在处理大量的数据,那么调整vfs_cache_pressure将是一个好主意。 再一次,找出正确的价值的唯一方法是反复试验,但是有一个非常高的扇出,可能不是大量的数据文件的阅读,然后减less它应该提高caching的有效性。

请注意,LVM快照将会终止IO吞吐量。

—-不pipe你select的文件系统如何,以上的东西都适用—-

当你select一个文件系统时最重要的考虑因素是你需要的强大程度。 如果这些文件都是临时文件,即使在停机的时候你也不介意丢失所有的文件,也不需要在停机后快速恢复,那么你根本就不应该使用日志文件系统。 但是你没有告诉我们这些数据。

注意到高扇出…. ext3 / 4的dir_indexfunction被明确地添加,以提供更快,更有效的解决scheme,当一个目录包含大量的文件/文件的高转换。 我不知道在这种情况下XFS有多有效。

ReiserFS不是很好的支持。

还有其他一些你可能想要看的东西(包括UPS,bcache,专用的期刊设备),但是我不会有借口来插上关于这个主题的书 。