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