c – 在NTFS上打开许多小文件太慢了

概述我正在编写一个应该处理许多小文件的程序,比如数千甚至数百万. 我一直在测试500k文件的那一部分,第一步就是迭代一个目录,里面有大约45k目录(包括子目录的子目录等)和500k小文件.遍历所有目录和文件,包括获取文件大小和计算总大小大约需要6秒.现在,如果我尝试在遍历时打开每个文件并立即关闭它,它看起来永远不会停止.事实上,它需要太长时间(小时……).自从我在 Windows上执行此 *** 作后,我尝试 我正在编写一个应该处理许多小文件的程序,比如数千甚至数百万.
我一直在测试500k文件的那一部分,第一步就是迭代一个目录,里面有大约45k目录(包括子目录的子目录等)和500k小文件.遍历所有目录和文件,包括获取文件大小和计算总大小大约需要6秒.现在,如果我尝试在遍历时打开每个文件并立即关闭它,它看起来永远不会停止.事实上,它需要太长时间(小时……).自从我在 Windows上执行此 *** 作后,我尝试使用CreatefileW,_wfopen和_wopen打开文件.我没有在文件上读或写任何东西,尽管在最后的实现中我只需要阅读.但是,我没有看到任何尝试都有明显的改善.

我想知道是否有一种更有效的方法来打开具有任何可用功能的文件,无论是C,C还是windows API,或者唯一更有效的方法是读取MFT并直接读取磁盘块,我我想避免？

更新：我正在处理的应用程序是使用版本控制进行备份快照.因此,它还具有增量备份. 500k文件的测试是在一个巨大的源代码库上完成的,以便进行版本控制,就像scm一样.因此,所有文件都不在一个目录中.还有大约45k目录(如上所述).

因此,建议的压缩文件解决方案没有帮助,因为当备份完成时,就是访问所有文件的时候.因此,我认为没有任何好处,甚至会产生一些性能成本.

解决方法 您要做的事情本质上是任何 *** 作系统都难以有效地执行. 45,000个子目录需要大量磁盘访问,无论它是如何切片的.

就NTFS而言,任何大约1,000字节的文件都是“大”的.如果有一种方法可以使大多数数据文件小于大约900字节,那么通过将文件数据存储在MFT中可以实现主要的效率.然后,获取数据并不比获取文件的时间戳或大小更昂贵.

我怀疑有没有办法优化程序的参数,过程选项,甚至 *** 作系统的调整参数,以使应用程序运行良好.您将面临多小时 *** 作,除非您能够以完全不同的方式重新构建它.

一种策略是将文件分布在多台计算机上 – 可能是数千台计算机 – 并在每个进程上有一个子应用程序本地文件,将任何结果提供给主应用程序.

另一个策略是将所有文件重新构建为一些较大的文件,如@felicepollano建议的大.zip文件,有效地虚拟化您的文件集.随机访问4000 GB文件本质上比访问40亿个1 MB文件更有效和更有效地使用资源.将所有数据移动到合适的数据库管理器(MySQL,sql Server等)中也可以实现这一点,并可能提供其他好处,如简单搜索和简单的归档策略.

总结

以上是内存溢出为你收集整理的c – 在NTFS上打开许多小文件太慢了全部内容，希望文章能够帮你解决c – 在NTFS上打开许多小文件太慢了所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。