代码之家 › 专栏 › 技术社区 › Elliveny

数百万个小图形文件以及如何克服XP上文件系统访问速度慢的问题

filesystems windows-xp google-maps performance

Elliveny · 技术社区 · 15 年前

我正在渲染数百万个图块,这些图块将在谷歌地图上显示为覆盖图。这些文件是由伦敦大学学院高级空间分析中心的GMAPCreator创建的。应用程序一次将文件呈现到一个文件夹中,在某些情况下,我需要创建大约420万个图块。我使用一个NTFS文件系统在Windows XP上运行它,磁盘为500GB,并使用默认的操作系统选项格式化。

我发现随着渲染瓷砖数量的增加,瓷砖的渲染速度越来越慢。我还看到,如果我试图查看Windows资源管理器中的文件夹或使用命令行,那么整个机器会有效地锁定几分钟,然后恢复到足以再次执行某项操作。

我一直在将输入的形状文件拆分成更小的部分,在不同的机器上运行,等等,但是这个问题仍然给我带来相当大的痛苦。我想知道我磁盘上的集群大小是否会妨碍这件事,或者我是否应该考虑完全使用另一个文件系统。有人知道我怎样才能克服这个问题吗?

谢谢,

巴里。

更新:

谢谢大家的建议。最终的解决方案是编写一段代码来监视gmapcreator输出文件夹,根据文件名将文件移动到一个目录继承结构中;因此名为a b c d e f g.gif的文件将被移动到\a\b\c\d\e\f\g.gif中。与gmapcreator同时运行它可以克服文件系统性能问题。关于生成DOS 8.3文件名的提示也是非常有用的——正如下面提到的,我很惊讶这有多大的区别。干杯:

5 回复 | 直到 15 年前

Community CDub 8 年前

你可以/应该做几件事

禁用自动生成NTFS短文件名(Google IT)
或者限制文件名使用8.3模式(例如i0000001.jpg,…)
在任何情况下,尝试使文件名的前六个字符尽可能唯一/不同
如果在和上使用相同的文件夹(例如添加文件、删除文件、读取文件…)
- 使用 contig 尽可能减少目录的索引文件的碎片(检查 this 解释)
- 尤其是在删除许多文件时,请考虑使用 folder remove trick 减小目录索引文件大小
正如已经发布的那样,考虑将文件拆分到多个目录中。

例如,代替

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

UpTheCreek 15 年前

你可以试试固态硬盘…

http://www.crucial.com/promo/index.aspx?prog=ssd

JSBÕ±Õ¸Õ£Õ¹ 15 年前

使用更多文件夹并限制任何给定文件夹中的条目数。枚举目录中条目数的时间增加(以指数形式?我不确定)如果你在同一个目录中有数百万个小文件,甚至做一些类似的事情 dir folder_with_millions_of_files 可能需要几分钟。切换到另一个fs或os并不能解决这个问题---上次我检查时,Linux有相同的行为。

找到一种方法将图像分组到每个不超过几百个文件的子文件夹中。使目录树尽可能深以支持这一点。

Brian Agnew 15 年前

该解决方案很可能会限制每个目录的文件数。

我有一个与20万份平面文件中的财务数据非常相似的问题。我们通过将文件存储在基于其名称的目录中来解决这个问题。例如

gbp97m.xls

存储在

g/b/p97m.xls

如果您的文件命名正确(我们有大量的字符可供使用),这就可以很好地工作。因此,结果目录树和文件在分布方面不是最佳的,但是它的工作足够好,可以将每个目录减少到100个文件,并释放磁盘瓶颈。

brianegge 15 年前

一种解决方案是实施草垛 . This is what Facebook does for photos, 由于获取文件所需的元数据和随机读取非常高,因此没有为数据存储提供任何价值。

Haystack提供了一个基于HTTP的通用对象存储,其中包含映射到存储的不透明对象的指针。将照片作为针存储在Haystack中,通过在单个Haystack存储文件中聚合数十万个图像,消除了元数据开销。这使得元数据开销非常小,并允许我们将存储文件中每个指针的位置存储在内存索引中。这允许在最少数量的I/O操作中检索图像的数据,从而消除所有不必要的元数据开销。