在我们的办公室，我们使用 SSD 的 RAID5 作为 Linux 服务器上的网络共享。此共享可作为网络驱动器从 Windows PC 和 Mac 访问。有时，此网络共享的访问时间和传输速度会变得非常慢。
我不是管理员，因此不完全了解该系统。
其中一位管理员现在提出，这可能与网络共享上存储的文件数量有关。有些文件夹包含数百万个几 kB 的文件。
访问速度是否取决于网络共享上的文件数量？
答案1
这并不是驱动器上的文件数量，而是给定文件夹中的文件数量。
每次有人访问文件夹时，必须读取内容才能显示文件列表。这也与文件大小无关；只需要获取标题、创建/修改日期和其他可见的信息。
如果使用缩略图，图标缓存也可能受到严重影响。
将这些巨大的文件夹分成子集可能正是结构所需要的。
答案2
速度清单文件显然取决于要列出的文件的数量。
速度开幕特定文件（即开始检索）能取决于文件的数量。
根据服务器上使用的文件系统（例如 NTFS、XFS、ext4、ZFS），它将使用不同的数据结构来存储每个目录中的文件列表 - 其中一些数据结构在处理海量列表方面明显优于其他数据结构（例如 B 树、哈希表和线性列表）。
每次打开（或以其他方式接触）新文件时，服务器都需要在该目录中找到它，这可能需要一些时间。（特别是如果目录列表未缓存在内存中并且需要从 HDD 读取。）
对于数百万个文件，您绝对应该考虑将它们分片到子目录中，例如基于文件名的前几个字母（类似于您在
.git/objects/Git 存储库中看到的）。速度转让文件的内容（不包括打开文件所需的时间）没有完全取决于该目录中的文件数量。
这确实取决于磁盘需要寻道多少（如果它们是机械的），这对于许多小文件来说尤其糟糕。
如果你要传输数千个小文件，我想大部分时间都会花在——如果服务器使用 HDD——物理上寻找 HDD 磁头在一个小文件和另一个小文件之间、在一个元数据条目和另一个元数据条目之间来回移动。
答案3
您没有说明服务器是 Windows 还是 Linux，但至少在基于 Linux 的文件系统中，大型目录肯定很慢。如果您在一个目录中创建数百万个文件，目录索引就会增长。如果您这样做，您实际上可以看到这一点ls -lhd <dir>。而且目录只会增长；它们不会变小。
我管理着一个处理许多队列文件的系统，为了避免因此导致系统速度变慢，我做了两件事：
- 将数百万个文件拆分到各个子目录中。这是一种非常常见的做法。例如，如果您查看 Postfix SMTP 服务器，您会看到队列目录根据首字母细分为子目录（这可以使用哈希或任何您想要的算法来完成）。
- 偶尔重新创建所有子目录。有些事件甚至会导致这些子目录增长，一旦目录大小达到几十或几百兆（不是内容（仅目录索引）会减慢对其的所有访问速度。
因此，避免在一个目录中放置数百万个文件并将它们放在子目录中。
当您谈论分布在许多子目录中的数百万个文件时，这不应该成为一个因素。
答案4
可能的瓶颈是网络接口。
这个问题的答案是“视情况而定”。这取决于操作系统、文件系统、文件共享协议、RAM、SSD 接口、是否使用静态加密以及如何使用、RAID 控制器等。
驱动器上的文件数量可能会影响性能 - 但这可能只是在偶尔读取文件和/或服务器内存非常受限时才会成为问题 - 文件系统指针通常保存在内存中，并且由于磁盘是 SSD，“寻道时间”不是问题。
也可能是一个或多个 SSD 即将达到使用寿命，或者无法正确处理 TRIM，在这种情况下，它可能会大大减慢读取速度，特别是写入速度，并可能不成比例地影响对其他磁盘的访问，因为数据被分散到所有磁盘上。