时间戳

首页 > 解决方案 > FabricDCA 和 MaxDiskQuotaInMB 配置

azure-service-fabric - FabricDCA 和 MaxDiskQuotaInMB 配置

问题描述

这个问题有两个部分。首先，什么属于 Diagnostics---MaxDiskQuotaInMB配置的范围？它是 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。

标签： azure-service-fabric

解决方案

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

SvcFab/Log 文件夹下的大部分内容都应该在 MaxDiskQuotaInMB 设置的配额范围内。有些东西可能不会，但通常会占用磁盘空间的大多数东西都包括在内。还要记住，清理磁盘的任务通常每 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 中已修复

推荐阅读