我们每天生成大约340万个小jpeg文件。 我们还删除了约340万个90天的旧图像。 迄今为止，我们已经通过以分层方式存储图像来处理这个内容。 这个犹太教是这样的：
/Year/Month/Day/Source/ 通过这种方式，我们可以有效地删除所有来源的天数内容。
这些文件存储在连接到14磁盘SATA RAID6的Windows 2003服务器上。
在写入和读取磁盘时，我们已经开始出现重大的性能问题。
这可能是由于硬件的性能，但我怀疑磁盘碎片可能是一个罪魁祸首。
有人build议将数据存储在数据库中，但我一直在犹豫。 另一个想法是使用某种容器文件，如VHD或其他东西。
有没有人有任何减轻这种碎片的build议？
附加信息：
平均文件大小是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
Diskeeper 2009（现在是2010）对实时碎片整理效果很好，对性能影响最小。 但是，由于这是一个商业包装，所以是有成本的。 我们尝试了几个免费的应用程序，发现重大的性能问题
Diskeeper主页
我从你的post中假设你保留了90天的图片。 做一些快速的math，看来你需要4.28TB的存储空间。 什么是I / O模式（比如更频繁地访问哪些数据）？ 你有多less卷这个数据传播？ 碎片整理后，性能降到不可接受的水平有多快？
如果您不愿意对系统进行更改（引入数据库），也许您应该关注如何使用与操作系统捆绑在一起的工具以可pipe理的方式进行碎片整理。 在多个较小的LUN上旋转和拆分数据，以便可以对它们进行单独的碎片整理。 写完X天数据后，移至下一个LUN，并使用之前的X天对卷进行碎片整理。 如果你不再写信给你，你不应该再引入更多的碎片。
如果您已经获得了相当可观的预算，则可以查看不受碎片影响的存储介质（例如SSD）。