FabricDCA 和 MaxDiskQuotaInMB 配置

FabricDCA and MaxDiskQuotaInMB Configuration

这个问题有两个部分。首先,什么属于诊断程序的权限---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,但到目前为止它也没有帮助(几个小时后)。

我们集群中的一个节点有太多 space 被日志占用(超过我们的限制),剩余存储 space 减少到 1 MB。

发布更完整的答案,因为它可能对其他人有帮助。

SvcFab/Log 文件夹下的大部分内容应在 MaxDiskQuotaInMB 设置的配额范围内。有一些东西可能不会,但大多数通常占用磁盘 space 的东西都包括在内。另请记住,清理磁盘的任务通常每 5 分钟运行一次,因此您可能会看到在此时间范围内使用量超过配额。

如果 FabricDCA.exe 没有正确清理此文件夹中的文件,则可能是您遇到了 .Net 运行时中的错误,其中所有 system.threading.timers 停止触发并且磁盘未被清理,因为 FabricDCA依靠这些计时器来做到这一点。 这是 .NET 核心端跟踪问题的错误:(https://github.com/dotnet/coreclr/issues/26771)。这似乎发生在机器 运行 间歇性内存不足时。

Service Fabric 7.0 的 FabricDCA 中添加了自动缓解功能。 手动缓解通常是杀死 FabricDCA.exe 进程。 该过程应重新开始,几分钟后它将再次开始清洁。

你提到你已经尝试杀死 FabricDCA.exe 所以上面的解决方案可能不适合你。在这种情况下,请尝试直接查看 Service Fabric 集群清单,这可能是您的新配置似乎已被 ARM 模板部署接受但新配置未到达作为源的集群清单的情况在这种情况下是真实的。

更新: 作为上述自动缓解的一部分引入了回归,导致 AppInstanceFolder 填满磁盘。这已在 SF 版本 7.0.466

中修复