azure-service-fabric - 为什么我的 Service Fabric 参与者使用比预期更多的磁盘空间？

Question

我试图理解为什么我们的 Actor 服务使用的磁盘空间比预期的多。我们的服务目前包含分布在 10 个分区上的大约 80,000 个参与者。每个参与者存储大约 150Kb 的状态。

查看我们集群中的一个(10 个)节点，我希望看到:

用于大约 3 个分区的磁盘空间(一个作为主分区，两个作为辅助分区)

这是预期的

深入到一个分区文件夹中，我希望只看到一个副本 ID

不像预期的那样:

我看到了预期的一个(与 Service Fabric Explorer 中节点部分下列出的副本匹配的那个)。副本 ID 以 R_ 为前缀

在同一个分区文件夹中，我看到其他 3 个文件夹的副本 ID 以前缀 S_ 开头。 .这些副本 ID 与 Service Fabric Explorer 中“应用程序”节点下列出的任何值都不匹配。

查看以 R_ 开头的副本文件夹，我希望该文件夹包含的大小不超过 8000 个 Actor 的大小，每个 Actor 占用大约 150 Kb，因此大约 1.14 Gb 的数据。

不像预期的那样:

该文件夹包含一个文件 ActorStateStore其大小为 5.66Gb

我试图理解的另一件事如下:

我们应用程序的版本 1 没有清理未使用的 actor。正如您所料，我们看到每个节点上的磁盘使用量稳步增长。

我们应用程序的第 2 版开始删除未使用的角色。由于此新代码将超过一半的活跃参与者，因此部署后我预期总体使用的磁盘大小将显着下降。

没有发生，增长停止了，但使用量并没有减少。

所以我的问题是:

我的期望是否正确？

什么可以解释我的观察？

Answer 1

Drilling down into one partition folder, I would expect to see just one replica id

如果事情已经运行了一段时间，我希望看到不止一个。这是因为两件事:

Service Fabric 至少在 ReplicaRestartWaitDuration 的时间内保留节点上发生故障的副本的信息。 .这样一来，如果本地恢复是可能的，节点上仍然有必要的信息。例如，如果副本刚刚发生故障并且无法彻底删除，则这些类型的文件可能会累积。如果有人“ForceRemoved”单独的副本，它们也可能存在，因为这明确跳过干净关闭。这就是为什么我们通常不建议在生产环境中使用此命令的部分原因。

还有一个称为“UserStandbyReplicaKeepDuration”的设置，它控制SF保留现在不需要的旧副本多长时间，以防以后需要它们(因为从部分状态重建通常比完整状态更便宜)。

一种。例如，假设某个副本所在的节点发生故障并且比 ReplicaRestartWaitDuration 停留的时间更长。对于该服务。当这种情况发生时，SF 会构建一个替换副本，让您恢复到您的 TargetReplicaSetSize .

湾假设一旦构建了副本，失败的节点就会回来。

C。如果我们仍在该副本的 StandbyReplicaKeepDuration 内，那么 SF 会将其留在磁盘上。如果在此期间出现另一个故障，SF 通常(取决于 Cluster Resource Manager 设置，该节点是否为有效目标等)选择此部分副本并从驱动器上剩余的内容重建替换。

因此，您可以看到过去的副本，其信息仍保留在驱动器上，但您通常不应看到比 UserStandbyReplicaKeepDuration 更旧的任何内容。 (默认为一周)。如果需要，您可以随时减少集群中的持续时间。

I would expect the folder to contain not much more than the size of 8000 actors taking up around 150 Kb each so around 1.14 Gb of data. Not as expected:The folder contains a file ActorStateStore and its size is 5.66Gb

这有点令人费解。让我们不要回到我们期望在给定节点上的东西数量。你说你有 80K Actor 。我想你有一个 TargetReplicaSetSize 3 个，所以这真的更像是 24 万个 Actor 。每个参与者都有大约 150K 的状态，因此集群有大约 34 GB 的状态。每个节点然后我们期望 3.4 GB 的状态。 (我认为您最初的估计忘记了复制。如果您的 TargetReplicaSetSize 实际为 1，请告诉我，我们可以重新计算。)

~3.4gb 更接近你观察到的 ~5.7gb，但还不够接近。其他一些注意事项:

序列化开销:actor 框架通常使用 NetDataContractSerializer 来序列化您的 actor 状态中的数据。您可能想测试一下，看看这是否会导致您的 150K 状态大 60%(这将是很多开销，但并非闻所未闻)

“剩女” Actor 。如果您正在动态创建副本，要记住的一件事是，在您告诉 SF 删除它们之前，它们不会被完全删除
var serviceUri = ActorNameFormat.GetFabricServiceUri(typeof(IMyActor), actorAppName);
var actorServiceProxy = ActorServiceProxy.Create(actorId.GetPartitionKey(), serviceUri);
await actorServiceProxy.DeleteActorAsync(actorId, cancellationToken);

The growth stopped but the usage did not shrink.

这可能只是在未重新打包/回收的数据存储级别分配的空间。我们需要查看实际仍在占用空间的内容以了解情况。其中一些取决于实际的持久性存储(ESE/KVS 与基于字典的状态提供程序)。作为升级的一部分，您生成的 ActorIds 也有可能发生了某种变化，因此新代码无法引用“旧”ActorIds(但感觉不太可能)。