![配置 NTFS 文件系统以提高性能](https://linux22.com/image/489521/%E9%85%8D%E7%BD%AE%20NTFS%20%E6%96%87%E4%BB%B6%E7%B3%BB%E7%BB%9F%E4%BB%A5%E6%8F%90%E9%AB%98%E6%80%A7%E8%83%BD.png)
我们有一个应用程序计划存储大约 1.1TB 的 XML 文件,这些文件平均大小为 8.5kb。
这些是连续 18 个月的数据,每天大约会创建 200,000 个新文件。
每个文件只会被写入一次,然后在接下来的 18 个月内有 3% 的概率被读取少量(<10)次。
有哪些 NTFS 选项可以帮助提高性能?
目前我们名单上的有:
- 禁用 8.3 名称创建
- 限制目录中的文件数量(数量仍有争议......)
编辑
关于碎片:我们计划使用 2k 簇大小来提高磁盘空间使用效率。每个文件只写入一次(即不编辑文件)。文件将在 18 个月后逐日删除。
因此,我们不认为碎片化会成为一个重大问题。
答案1
我还要补充一点:
关闭磁盘碎片整理。将块大小更改为 16kb,以便每个文件都写入单个块中。
这样做的理由是:
您希望每天写入 1.7GB 的数据,共 200,000 个文件。假设这些文件在一天 24 小时内写入,这意味着每秒大约 3 个文件。对于单个 SATA 磁盘来说,这似乎不是什么大问题,所以我猜您除了磁盘性能之外还存在其他问题。
(即,您有足够的内存吗?或者您是否也将内存分页到磁盘?)
然而
Windows NTFS 文件系统默认尝试在后台对文件系统进行碎片整理。在对磁盘进行碎片整理时,磁盘碎片整理会降低性能。由于性能似乎已经成为一个问题,这只会让情况变得更糟。
在写入大型文件时,使用较小的簇大小和 IO 性能之间存在平衡。文件和文件分配表不会位于磁盘上的同一扇区上,因此在写入文件时必须分配块会导致磁盘头不断移动。使用能够将 95% 的文件存储在一个簇中的簇大小将提高 IO 写入性能。
正如其他人指出的那样,使用 2k 的小簇大小会随着时间的推移造成碎片。可以这样想,在前 18 个月内,您将文件写入干净的空磁盘,但操作系统不知道一旦关闭,就不会再向每个文件添加数据,因此它在每个文件的末尾都留了一些可用的块,以防该文件稍后被扩展。在填满磁盘之前,您会发现唯一的可用空间是在其他文件之间的间隙中。不仅如此,当它为您的文件选择间隙时,操作系统不知道您正在写入 5 个块的文件还是 2 个块的文件,因此它无法做出正确的选择来保存文件的位置。
归根结底,工程就是处理相互冲突的需求,并选择成本最低的解决方案来平衡这些需求。我猜想购买更大的硬盘可能比购买更快的硬盘更便宜。
答案2
禁用最后访问时间戳并为 MFT 保留空间。
答案3
详细说明我对托勒密的回答的评论......
通过设置块大小,使每个文件的绝大部分都包含在一个块中,您确实可以获得 I/O 效率。如果块大小为 2K,平均文件大小为 8.5K,则 50% 的 I/O 操作将针对 5 个或更多块。通过设置 16K 块大小,听起来绝大多数写入操作将针对单个块;这将使这 3% 的读取操作更加高效。
需要考虑的一件事是备份 I/O。如果您要备份数据,则每个文件将至少被读取一次,并且每次备份时都会检查其目录条目。如果您要备份,请在设计中考虑备份 I/O。
注意事项:如果您的底层存储系统已经进行了一些存储虚拟化(例如 HP EVA 磁盘阵列或该类的其他阵列),那么这并不重要。这种类型的碎片不会被注意到,因为数据在实际驱动器上已经以高度碎片化的形式物理存在。在这种情况下,2k 块大小就足够了,不会对性能产生太大影响。通过选择足够大的块大小来容纳大多数预期文件大小,仍然可以提高性能,但幅度不会那么大。
答案4
您可能还想在设计中研究 RAID。RAID 有多种形式,但最好研究 RAID 5,它允许您同时将文件写入不同的驱动器,但数据仍位于一个卷上……这为您带来了多种好处:
1) 您正在创建备份。这样,即使驱动器崩溃,您也可以恢复。RAID 1 将创建镜像副本,但 5 涉及条带化 - RAID 1 只会给您带来该备份的好处……尽管 5 会涉及更多内容,并且您需要更多驱动器来设置它(至少需要 3 个,而 RAID 1 需要 2 个),但您还有其他好处。
2) 条带化还可以提高性能,因为您可以同时写入多个文件(估计每秒 3 个,以上...),条带化将允许文件沿磁盘“分布”,并且每个磁盘仅承担一部分负担。涉及的磁盘越多,每个磁盘的负担越轻,但总有一天您会达到性能与成本的极限...
3)如果您备份数据,则可以在不降低任何写入性能的情况下进行备份 - 当然,这取决于磁盘缓存的大小以及备份的形式......但在大多数情况下,您不需要关闭来调用备份。
此外,您设置系统的方式听起来似乎备份对您来说会更容易 - 您只需要一次备份 24 小时的数据,因为文件以后不会被修改。如果您担心文件占用的空间,您甚至可以编写一个压缩数据的批处理作业... XML 主要是文本,因此压缩率会很高,并且很少需要解压缩,只有 3% 的文件需要解压缩...因此您可以在驱动器上包含压缩而不必担心解压缩时间。这还可以减少所需的块大小,并可以进一步提高系统的效率,因为 CPU 参与压缩数据,而不仅仅是数据的中间人。(即,如果您所做的只是存储数据,那么该系统中那个不错的 CPU 处理器就是浪费了...但是如果它使用“浪费的”时钟周期,压缩数据并更有效地分发到驱动器,那就更好了!)
经过压缩后,您的 2K 块可能可以毫无问题地容纳 8.5K 文件。添加条带化和 RAID 备份,以及强大的 CPU 和足够的内存以不缓存任何正在运行的程序(如果使用任何缓存),您就可以获得一个适合自己需要的系统。