≈13.5万份

NTFS | Windows 2012 server | 64bit | 4tb HDD | VBS

问题:当[单个]特定文件夹聚集了大约135,000个文件时，会出现灾难性的硬件问题。

“灾难性”= CPU过热，计算机关闭，更换硬件需要 "Specific Folder" =有一个VBS文件，用于将文件移动到子文件夹中 访问=该文件夹被多个客户端计算机自动访问/执行

基本上，我有一个位于文件服务器上的定制脚本。当自动化过程出现问题时(例如，文件溢出+大坝)，那么特定的文件夹会被淹没[未移动的文件]。当客户端计算机继续执行脚本时，灾难就形成了。文件服务器最终读取了135,000多个文件;每天这样做几百次。这种工作过载最终导致我的CPU过热(92°C等);结果导致我的机器崩溃。

解决方案:确保您的文件组织脚本永远不必处理包含135,000多个文件的文件夹。

这实际上取决于所使用的文件系统，以及一些标志。

例如，ext3可以有数千个文件;但在几千次之后，它就变得非常缓慢了。主要是在列出目录时，但也在打开单个文件时。几年前，它获得了“htree”选项，这极大地缩短了给定文件名获取inode所需的时间。

就我个人而言，我使用子目录将大多数级别保持在1000个左右的项目以下。在您的例子中，我将创建256个目录，使用ID的最后两个十六进制数字。使用最后一个数字，而不是第一个数字，这样可以实现负载平衡。

不是答案，只是一些建议。

选择一个更合适的FS(文件系统)。因为从历史的角度来看，你们所有的问题都是足够明智的，在过去几十年里曾经是金融服务体系演变的核心。我的意思是更现代的FS更好地支持你的问题。首先从FS列表中做出一个基于你最终目的的比较决策表。

我认为是时候改变你的思维模式了。所以我个人建议使用分布式系统支持的FS，这意味着在大小、文件数量等方面没有任何限制。否则，你迟早会遇到意想不到的新问题。

我不确定这是否有效，但如果您没有提到一些实验，请尝试一下当前文件系统上的AUFS。我想它可以将多个文件夹模拟为单个虚拟文件夹。

为了克服硬件限制，可以使用RAID-0。

这在一定程度上取决于Linux服务器上使用的特定文件系统。现在默认是ext3和dir_index，这使得搜索大目录非常快。

所以速度不应该是一个问题，除了你已经注意到的问题，那就是上市需要更长的时间。

一个目录下的文件总数是有限制的。我记得它可以运行到32000个文件。

我现在正在研究一个类似的问题。我们有一个层次结构的目录结构，并使用映像id作为文件名。例如，其中放置了id=1234567的图像

..../45/67/1234567_<...>.jpg

使用最后4位数字来确定文件的位置。

对于几千张图像，您可以使用一级层次结构。出于效率/备份/其他考虑，系统管理员建议在任何给定目录(ext3)中不超过几千个文件。

这完全取决于文件系统。许多现代文件系统使用良好的数据结构来存储目录的内容，但旧的文件系统通常只是将条目添加到列表中，因此检索文件是一个O(n)操作。

即使文件系统做得正确，列出目录内容的程序仍然绝对有可能搞砸并执行O(n^2)排序，因此为了安全起见，我总是将每个目录的文件数量限制在不超过500个。