我们每天生成约 340 万个小型 jpeg 文件。我们还删除了约 340 万张 90 天前的图片。到目前为止,我们通过以分层方式存储图片来处理这些内容。层次结构如下:
/Year/Month/Day/Source/
这种层次结构使我们能够有效地删除所有来源中几天的内容。
文件存储在连接到 14 个磁盘 SATA RAID6 的 Windows 2003 服务器上。
我们在写入和读取磁盘时开始遇到严重的性能问题。
这可能是由于硬件的性能,但我怀疑磁盘碎片也可能是罪魁祸首。
有些人建议将数据存储在数据库中,但我一直犹豫不决。另一个想法是使用某种容器文件,例如 VHD 之类的东西。
有谁能给出一些建议来缓解这种碎片化现象吗?
附加信息:
平均文件大小为8-14KB
来自 fsutil 的格式信息:
NTFS Volume Serial Number : 0x2ae2ea00e2e9d05d
Version : 3.1
Number Sectors : 0x00000001e847ffff
Total Clusters : 0x000000003d08ffff
Free Clusters : 0x000000001c1a4df0
Total Reserved : 0x0000000000000000
Bytes Per Sector : 512
Bytes Per Cluster : 4096
Bytes Per FileRecord Segment : 1024
Clusters Per FileRecord Segment : 0
Mft Valid Data Length : 0x000000208f020000
Mft Start Lcn : 0x00000000000c0000
Mft2 Start Lcn : 0x000000001e847fff
Mft Zone Start : 0x0000000002163b20
Mft Zone End : 0x0000000007ad2000
答案1
Diskeeper 2009(现为 2010)在实时碎片整理方面表现良好,对性能的影响最小。但是,由于它是一个商业软件包,因此需要付费。我们尝试了几个免费应用程序,发现存在严重的性能问题。
答案2
我从您的帖子中推测您保留了 90 天的图片。通过快速计算,您似乎需要 4.28TB 的存储空间。I/O 模式是什么样的(即是否有任何数据访问频率更高)?这些数据分布在多少个卷上?碎片整理后,性能多久会下降到不可接受的水平?
如果您不愿意对系统进行更改(引入数据库),也许您应该专注于如何使用与操作系统捆绑在一起的工具以可管理的方式进行碎片整理。将数据轮换并拆分到多个较小的 LUN 上,以便您可以单独对它们进行碎片整理。在完成 X 天的数据写入后,移动到下一个 LUN 并使用前 X 天的数据对卷进行碎片整理。如果您不再写入它,则不应再引入任何碎片。
如果您有足够的预算,您可能会考虑一种不易产生碎片的存储介质(例如 SSD)。