有几台服务器，它们已经两年没有进行碎片整理了。在碎片整理之前应该碎片化的百分比是否有标准？
服务器是 Windows 2003。
AskOverflow.Dev
有几台服务器，它们已经两年没有进行碎片整理了。在碎片整理之前应该碎片化的百分比是否有标准？
服务器是 Windows 2003。
事实上，我从不对服务器上的数据进行碎片整理。我还没有看到文件服务中的性能提升足以使它值得花时间进行碎片整理的性能损失。事实上，除非您让它们离线几天，否则大多数服务器永远不会真正完成碎片整理。如果您使用的是相对现代的文件系统（除非您选择更改 Windows 2003 上的默认设置），那么无论如何这都无关紧要。此外，如果您正在运行任何类型的条带化 RAID，则文件碎片不是问题，因为它们已经在许多磁盘上分解。
如果我有一台服务器，出于某种原因我真的希望数据清理和碎片整理，我更有可能将其全部备份到磁带上，擦除驱动器并恢复它。这会将它们全部写在完美的块中。
我所知道的对 Windows 服务器进行碎片整理的唯一用例是提高备份性能。备份几乎是文件服务器执行的唯一大规模顺序 I/O，而且这种 I/O 会注意到碎片。当用户访问它们时，I/O 文件服务器的行为是非常随机的，在这种情况下，碎片有时可以提高性能。
在我以前的工作中，我们有一个文件服务器，我们刚刚迁移到新硬件。迁移后，备份立即以 450MB/分钟的速度运行（请注意，这是很多年前的事了）。两年后，该服务器的备份速度约为 300MB/分钟。然后我们第一次对其进行碎片整理，速度再次回升至 450MB/分钟。
如果您无法按时完成所有备份，并且看起来正在备份的服务器是瓶颈，那么碎片整理可能会有所帮助。
碎片整理的另一个用例是备份到磁盘系统，存档存储在 NTFS 上。这种卷上的备份和恢复是完全顺序的，并且会注意到碎片。但是，如果底层存储足够抽象（例如 HP EVA 磁盘阵列），即使这种 I/O 也不会注意到碎片。
这一切归结为大规模顺序 I/O 是最容易注意到碎片的 I/O 类型。如果这不是您关心的 I/O，那么碎片整理就不是问题。
我同意，如果性能是您的目标（不断的碎片整理弊大于利），您通常不需要也不应该这样做。
像任何规则一样，但也有一些例外：
如果你是，或者在某个时候磁盘空间非常低（<15% 可用），那么你可能应该在有时间的时候进行碎片整理。当可供选择的扇区如此之少时，即使是现代文件系统也难以避免碎片化。
如果您正在运行导致不可避免的碎片的特定类型的应用程序，您可能希望投资于服务器特定的碎片整理程序（这些程序旨在在后台连续运行并在需要时进行碎片整理）。在 Windows 环境中会导致不可避免的碎片化的应用程序类型是那些在多个文件之间进行大量延迟写入的应用程序（大多数强大的服务器设计软件会避免这种情况，但桌面下载管理器之类的东西，尤其是某些特定的 BitTorrent 客户端，表现出这种激进的碎片行为）
我在早期的工作中在服务器上运行了 Diskeeper，因此文件服务器和应用程序服务器的性能都得到了显着提升。我认为我们没有接近他们公布的统计数据，但我们确实看到了一些好处。
它被设置为在空闲和设置的时间表中进行碎片整理，以限制在启动时启动的一些额外位的影响。
IOBit 的 Smart Defrag 是一种工具。当您的计算机空闲时，它会在后台进行碎片整理，并具有深度优化和其他功能。它看起来很有用，所以你可以把它放在那里而不必担心碎片整理。
AFAIK，RAID 不能免受碎片化影响；尽管有物理磁盘的数量，FS 仍然必须为每个片段发出单独的 I/O 请求，对吧？
是的，一个经过良好碎片整理的系统可以更快地完成备份。也同意低空间和碎片化不是一个好的组合......最好避免这种情况。
如果碎片整理时间/计划是一个问题，像 Diskeeper Server 版本（不是免费的！）这样的后台碎片整理解决方案是一个不错的选择。它仅使用空闲资源进行碎片整理，因此即使对生产服务器也应该没有影响。我们这里的一些服务器使用 DK，管理员似乎对此很满意。
顺便说一句，一些 BT 客户端（想到 utorrent）有一个用于 torrent 的预分配选项，所以在下载过程中没有碎片，只要有足够的连续可用空间来容纳文件。
共识（我同意）似乎是不要在服务器上进行碎片整理，因为这些好处不值得在实际碎片整理期间对性能造成影响。
但是，TechNet 关于进行物理到虚拟转换的文章建议将碎片整理作为一种减少执行 P2V 所需时间的方法。如果您完成 P2V 的维护窗口有限，这一点尤其重要。