这个问题有两个部分。首先，诊断的权限范围是什么---MaxDiskQuotaInMB configuration ？是 SvcFab/Log 下的所有内容吗？只是 SvcFab/Log/AppInstanceData/？如果有更多这方面的信息就好了。
其次，如果 FabricDCA.exe 正在运行，但 SvcFab/Log 和 SvcFab/Log/AppInstanceData/文件夹超出了我们对其大小设置的限制，正确的操作过程是什么？我的团队将它们设置为 10,000 MB，但 SvcFab/Log 通常占用 12-16 GB。
Azure 上的群集配置可识别对 MaxDiskQuotaInMB 配置的更改，但似乎对节点本身没有影响。我也尝试过重置 FabricDCA.exe，但到目前为止它也没有帮助(几个小时后)。
我们集群中的一个节点被日志占用了太多空间(超出了我们的限制)，导致剩余存储空间减少到 1 MB。
最佳答案
发布更完整的答案，因为它可能对其他人有帮助。
SvcFab/Log 文件夹下的大部分内容都应在 MaxDiskQuotaInMB 设置的配额范围内。有一些内容可能不包含在内，但大多数通常占用磁盘空间的内容都包含在内。另请记住，清理磁盘的任务通常每 5 分钟运行一次，因此您可能会看到在此时间范围内使用量超过配额。
如果 FabricDCA.exe 未正确清理此文件夹中的文件，则可能会遇到 .Net 运行时中的错误，其中所有 system.threading.timers 停止触发并且磁盘不会被清理，因为 FabricDCA 依赖于这些计时器这样做。 这是 .NET Core 端跟踪问题的错误:( https://github.com/dotnet/coreclr/issues/26771 )。当机器间歇性地耗尽内存时，似乎会发生这种情况。
Service Fabric 7.0 中的 FabricDCA 添加了自动缓解功能。 手动缓解通常是终止 FabricDCA.exe 进程。 该过程应该再次开始，几分钟后它将再次开始清洁。
您提到您已经尝试杀死 FabricDCA.exe，所以上面的解决方案可能不适合您。在这种情况下，请尝试直接查看 Service Fabric 群集 list ，可能会出现这样的情况:您的新配置似乎已被 ARM 模板部署接受，但新配置未到达作为来源的群集 list 。在这种情况下是事实。
更新: 作为上述自动缓解的一部分引入了回归，导致 AppInstanceFolder 填满磁盘。这在 SF 版本 7.0.466 中已修复
关于azure-service-fabric - FabricDCA 和 MaxDiskQuotaInMB 配置，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/59185449/