[注意 翻译者。 本文适用于Windows Server 2003 / 2003R2 / 2008 / 2008R2，但以上大部分内容适用于更高版本的操作系统]沃伦又来了。 本文是有关如何正确计算DFSR正常运行所需的最小登台文件夹大小的快速参考指南。 设置较低的值可能会减慢复制甚至停止复制。 请记住，这些只是
最小值 。 在确定中间文件夹的大小时，请记住以下几点：中间文件夹的大小越大，越好，直到复制文件夹本身的大小为止。 有关使用正确大小的暂存文件夹的重要性的更多信息，请参见“如何确定暂存文件夹是否存在问题”一节和本文末尾链接的博客文章。
更新：沃伦真的知道如何说服！ 现在有一个修复程序，您可以使用该修复程序来计算登台文件夹的大小。
https://support.microsoft.com/kb/2607047经验法则
Windows Server 2003 R2 —登台文件夹配额应与已复制文件夹中9个最大文件的总大小相同。
Windows Server 2008和2008 R2-登台文件夹配额必须与复制的文件夹中32个最大文件的总大小相同
[注意 翻译者。 此数字也适用于Windows Server 2012 / 2012R2]与正常的日常复制相比，主复制在临时文件夹中使用的空间要大得多。 如果磁盘空间大小允许，则强烈建议在开始主复制之前将大小设置为超出所需的最小值。
从哪里获得PowerShell？
Windows 2008及更高版本随附PowerShell。 它必须安装在Windows Server 2003上。
在此处下载适用于Windows 2003的PowerShell。
如何找到这些最大的文件？
使用PowerShell脚本查找32个或9个最大的文件，并确定它们占用了多少GB（由于PowerShell命令使用Ned Pyle）。 我想向您介绍三个PowerShell脚本。 它们中的每一个都以其自己的方式有用，但是，第3个是最有用的。
- 运行：
Get-ChildItem c:\temp -recurse | Sort-Object length -descending | select-object -first 32 | ft name,length -wrap -auto
此命令返回文件名及其大小（以字节为单位）。 找出复制文件夹中最大的32个文件并访问其所有者很有用。
- 运行：
Get-ChildItem c:\temp -recurse | Sort-Object length -descending | select-object -first 32 | measure-object -property length –sum
此命令返回文件夹中32个最大文件的总字节数，而不指定其名称。
- 运行：
$big32 = Get-ChildItem c:\temp -recurse | Sort-Object length -descending | select-object -first 32 | measure-object -property length –sum $big32.sum /1gb
此命令获取文件夹中32个最大文件的字节总数，并使用数学计算将其转换为GB。 该命令由两行组成。 您可以一次将它们粘贴到PowerShell命令外壳中，或依次运行它们。
人工分析
为了演示该过程，并在可能的情况下加深我们对正在做的事情的理解，我们将逐一进行每个操作并手动执行。
第一个正在运行的命令将返回类似于以下所示的结果。 为简便起见，此示例仅需要16个文件。 对于Windows 2008和更高版本的操作系统，始终考虑32个文件，对于Windows 2003 R2，则始终考虑9个文件。
PowerShell返回的样本数据：
| 名称 | 长度 |
|---|
| File5.zip | 10286089216 |
| archive.zip | 6029853696 |
| BACKUP.zip | 5751522304 |
| file9.zip | 5472683008 |
| MENTOS.zip | 5241586688 |
| File7.zip | 4321264640 |
| file2.zip | 4176765952 |
| frd2.zip | 4176765952 |
| BACKUP.zip | 4078994432 |
| File44.zip | 4058424320 |
| file11.zip | 3858056192 |
| Backup2.zip | 3815138304 |
| BACKUP3.zip | 3815138304 |
| Current.zip | 3576931328 |
| Backup8.zip | 3307488256 |
| File999.zip | 3274982400 |
如何使用此数据确定暂存文件夹的最小大小：
- 名称=文件名
- 长度=大小（以字节为单位）
- 1 GB = 1073741824字节
首先，您需要计算字节总数。 然后将结果数字除以1073741824。我建议使用Excel或其他用于这些计算的电子表格编辑器。
基于示例的计算在上面的示例中，字节总数为75241684992。要获得中间配额的最小所需大小，您需要将75241684992除以1073741824。
75241684992/1073741824 = 70.07（GB）
根据数据，我将登台文件夹的大小设置为71 GB，四舍五入为整数。
实际应用
尽管手动分析是一件有趣的事，但花费时间并不是最好的事情。 要自动执行此过程，请使用上面示例中的第3条命令。 结果将是这样的：
使用第三个示例中的命令，无需进行任何计算（不计算取整），就可以确定d：\ docs文件夹的中间配额为6 GB。
我是否需要重新启动服务器或重新启动服务以应用更改？
为了使对登台文件夹的配额所做的更改生效，没有必要重新启动服务器或重新启动服务。 要应用更改，您将需要等待AD复制和AD中DFSR对象的轮询周期完成。
如何识别暂存文件夹中的问题
通过跟踪DFSR服务器日志中的特定事件代码来检测中间文件夹问题。 以下是这些事件的列表：4202、4204、4206、4208和4212。下面介绍了这些事件。 重要的是要了解事件4202和4204之间以及其他事件之间的区别。 事件4202和4204可以在正常操作期间大量记录。 将事件4202和4204视为脉搏，而4206、4208和4212类似于胸痛。 下面，我将解释如何解释事件4202和4204。
登台文件夹相关事件[注意 翻译者。 下面描述的日记事件以它们在Windows Server 2012 R2的俄语本地化版本中出现的形式显示。]编码：
4202等级：
警告DFS复制发现，具有本地路径<path>的已复制文件夹使用的暂存空间已超过其上限。 该服务将尝试删除最旧的中间文件。 这可能会影响性能。
编码：
4204级别：
信息DFS复制服务成功删除了具有本地路径<path>的复制文件夹的旧中间文件。 中间空间现在低于上限。
编码：
4206等级：
警告DFS复制服务无法清除本地路径<path>上已复制文件夹的旧中间文件。 该服务可能无法复制某些大文件，并且复制的文件夹可能变得不同步。 服务将在<X>分钟内自动尝试重新清理临时区域。 如果服务检测到某些中间文件已被解锁，则服务可能会更快开始清洁。
代号：
4208等级：
警告DFS复制发现临时空间超出了本地路径<path>上已复制文件夹的临时配额。 复制一些大文件，复制的文件夹可能会变得不同步。 该服务将自动尝试重新清洁暂存区。
编码：
4212级别：
错误DFS复制服务无法复制具有本地路径<path>的复制文件夹，因为中间路径无效或不可用。
事件4202和4208有什么区别？
事件4202和4208具有类似的描述，即 DFSR检测到登台文件夹占用的大小超出限制。 不同之处在于，中间文件夹清理过程开始后立即记录事件4202，而中间配额仍被超出。 事件4202是正常正常运行的标志，而事件4208则表明偏离标准并需要干预。
多少个事件4202和4204被认为太大？
这个问题没有单一答案。 与事件4206、4208和4212始终指示不良情况并指示需要采取行动相比，事件4202和4204也在正常操作期间发生。 频繁事件4202和4204
可能指示问题。 要考虑的事实：
- 在主文件夹复制期间，是否为复制文件夹（RF）记录了4202个事件？ 如果是这样，则事件4202和4204是正常的。 如果您希望在初始同步期间将这些事件的数量减少到最少，则可以通过增加中间文件夹的大小来实现。
- 仅计算4202个事件的总数是不够的。 您需要知道其中有多少适用于特定的RF。 如果在24小时内日记中有20个4202事件与一个文件夹相关，那么这很多。 但是，如果您有20个复制的文件夹，并且每个文件夹都有一个事件，则一切正常。
- 为了识别趋势，您需要分析几天收集的信息。
我通常建议客户在正常运行期间，每个复制文件夹在一天中最多允许一个4202事件。 “正常”表示不会进行主复制。 我用以下推理来证明这一点：
- 清理登台文件夹所花费的时间是文件复制所花费的时间。 清理暂存文件夹时，复制将暂停。
- 如果为中间设备分配了足够的空间，将其用于RDC和跨文件RDC以及将相同文件复制到其他复制成员，则DFSR可以更有效地工作。
- 记录的事件4202和4204越多，遇到DFSR无法清除暂存文件夹或被迫过早删除暂存文件夹的情况的可能性就越高。
- 以我的经验，事件4206、4208和4212总是可以预见的，并伴随着大量事件4202和4204。
遵循“每个RF每天最多不超过4202个事件”的规则，将大大减少暂存文件夹出现问题的可能性，并帮助DFSR服务器更有效地将资源用于其预期目的-文件复制。
附加信息
https://blogs.technet.com/b/askds/archive/2010/03/31/tuning-replication-performance-in-dfsr-especially-on-win2008-r2.aspxhttps://blogs.technet.com/b/askds/archive/2007/10/05/top-10-common-causes-of-slow-replication-with-dfsr.aspx沃伦·威廉姆斯“超过了我的配额”