我正在渲染数百万个瓷砖，这些瓷砖将在Google地图上显示为叠加层。这些文件由伦敦大学学院高级空间分析中心的GMapCreator创建。应用程序一次将文件呈现到一个文件夹中，在某些情况下我需要创建大约420万个图块。我在Windows XP上使用NTFS文件系统运行它，磁盘为500GB，并使用默认的操作系统选项进行格式化。
我发现随着渲染图块数量的增加，图块的渲染变得越来越慢。我还看到，如果我尝试在Windows资源管理器中查看文件夹或使用命令行，那么整个机器会在恢复到足以再次执行某些操作之前有效锁定几分钟。
我一直在将输入的shapefile分成小块，在不同的机器上运行等等，但这个问题仍然给我带来了相当大的痛苦。我想知道我的磁盘上的群集大小是否会阻碍这个问题，或者我是否应该完全使用其他文件系统。有没有人有任何想法我怎么能够克服这个问题？
谢谢，
百里
更新
感谢大家的建议。最终的解决方案包括编写一段监视GMapCreator输出文件夹的代码，根据文件名将文件移动到目录层中;所以名为abcdefg.gif的文件将被移动到\ a \ b \ c \ d \ e \ f \ g.gif中。在GMapCreator的同时运行它可以克服文件系统性能问题。关于生成DOS 8.3文件名的提示也非常有用 - 如下所述，我惊讶于它产生了多大的不同。干杯： - ）
答案 0 :(得分：5)
你可以/应该做的事情
或限制文件名使用8.3模式（例如i0000001.jpg，...）
在任何情况下，请尽量使文件名的前六个字符尽可能唯一/不同
如果你使用相同的文件夹和（比如添加文件，删除文件，读取文件......）
如上所述，请考虑将文件拆分为多个目录。
.e.g。而不是
directory/abc.jpg
directory/acc.jpg
directory/acd.jpg
directory/adc.jpg
directory/aec.jpg
使用
directory/b/c/abc.jpg
directory/c/c/acc.jpg
directory/c/d/acd.jpg
directory/d/c/adc.jpg
directory/e/c/aec.jpg
答案 1 :(得分：1)
你可以试试SSD ......
答案 2 :(得分：1)
使用更多文件夹并限制任何给定文件夹中的条目数。枚举目录中条目数的时间（以指数方式？我不确定）具有条目数，并且如果在同一目录中有数百万个小文件，甚至做类似{{1可能需要几分钟。切换到另一个FS或OS无法解决问题---上次检查时，Linux具有相同的行为。
找到一种方法将图像分组到每个不超过几百个文件的子文件夹中。使目录树尽可能深，以支持它。
答案 3 :(得分：0)
解决方案最有可能限制每个目录的文件数。
我在大约200,000个平面文件中保存的财务数据存在类似的问题。我们通过根据文件名将文件存储在目录中来解决它。 e.g。
gbp97m.xls
存储在
中g/b/p97m.xls
如果您的文件命名正确（我们有一些字符可供使用），这样可以正常工作。因此，生成的目录和文件树在分发方面不是最佳的，但它足以将每个目录减少到100个文件并释放磁盘瓶颈。
答案 4 :(得分：0)
一种解决方案是实施 haystacks 。 This is what Facebook does for photos,因为获取文件所需的元数据和随机读取非常高，并且没有为数据存储提供任何价值。
Haystack提供了一个基于HTTP的通用对象存储，其中包含映射到存储的不透明对象的针。通过在单个干草堆存储文件中聚合数十万个图像，可以将照片存储在大海捞针中，从而消除了元数据开销。这使元数据开销非常小，并允许我们将每个针的位置存储在内存索引中的存储文件中。这允许在最少数量的I / O操作中检索图像的数据，从而消除所有不必要的元数据开销。