100% cpu 使用率（最大）的 CpuShares 的服务结构代码包值
Service fabric code package value of CpuShares for 100% cpu usage(max)
我有 2 个服务结构应用程序 (sln) 和 3 个服务（3 个代码包）。我想以最大 CPU 百分比的 40% 20% 20% 分配它们，而不考虑核心，即对 CPU 核心的数量没有限制（当前机器是 4 核心逻辑）。根据以上 content/blog，如果我指定 CpuShares = 512、CpuShares = 256 和 CpuShares = 256，那么它应该占 40%、20%、20% 的最大值 CPU。然而，情况并非如此，它只允许各自服务的最大 CPU 使用量的 5%、2% 和 2%。通过阅读此 post (https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-resource-governance)
我认为 1024 是 CpuShares 的默认值（最大值），经过大量尝试和错误后，如果我们应用任何大于此的值，我最终得出 CpuShares 的值 10,000，我们会在服务资源管理器中收到错误消息，说 CpuShare 的参数无效。
所以考虑到 10,000 = 100% CPU 允许使用。我在测试中将上面的 CPU 共享值修改为 CpuShares = 4000、CpuShares = 2000 和 CpuShares = 2000 我可以看到最大 CPU 百分比使用率，其中 40% 20% 20%（不是精确的 5% 方差).所以问题是我无法在任何文档中找到 10,000 = 100% CPU 使用值。所以我想确认这是否正确，如果不正确，我该如何将服务或代码包限制为特定百分比。请帮忙解决这个问题
关于 SF 中服务资源治理的一个常见误解是，它是为您的服务保留和隔离的资源容量，就像它在 docker 容器上一样，但事实并非如此。
这些指标只是保持集群中服务平衡的软限制，并不意味着它们专门为您的服务保留，如果没有设置限制，其他服务可以并且将消耗这些资源。
For resource limit enforcement to work, all code packages within a service package should have memory limits specified.
指标是在集群中找到适当的服务平衡并将服务放置在具有可用资源的节点中的措施，因此假设您有服务 A、B 和 C，并且每个服务都有特定数量的资源需求, 比方说Memory，这是一个容易理解的值，A=1000MB，B=512MB，C=512MB，a节点有2GB内存，这些可以放在同一个节点，假设服务C需要1000MB，当需要激活服务 C 时，它会避开激活 A 和 B 的同一个节点，因为它没有能力在那里 运行，即使这些服务没有消耗所有请求的资源，另一个将选举节点。
来自docs：
The Service Fabric runtime currently does not provide reservation for
resources. When a process or a container is opened, the runtime sets
the resource limits to the loads that were defined at creation time.
Furthermore, the runtime rejects the opening of new service packages
that are available when resources are exceeded.
关于您关于股份的主要问题：
相同的文档描述了份额是保留的 CPU 核心保留给服务包的一部分，该服务包在该节点上激活的所有代码包之间分配，如果您为每个代码包定义份额，相加为总和，每人获得一定比例的份额。
这些股份是如何控制的？
Keep in mind the below are not officially documented anywhere and I might be wrong in some aspects, I've got this information from the source code and I might have missed some details
假设激活了包含代码包 A 和 B 的服务包，并进行以下份额拆分：
- 代码包A (CP.A) = 1500股
- 代码包B (CP.B) = 500股
顺丰将：
- 确定为服务包预留的CPU核心容量：
- 容量将是CPU核心预留容量（%）/总可用容量
- 4 核 cpu: 1 cpu 保留核心 = 25%
- 从代码包中获取所有份额并对它们的值求和以确定应代表 100% 的保留 (25%) 容量的份额
- 1500 + 500 = 2000 总股数
- CP.A 应该得到 4
的 3 个分数
- CP.B 应该得到 1 的 4
- 将份额分数转换为 CPU 工作周期（请参阅下文原因）
- CP.A 应该收到 10,000 的 3/4 -> 7500 个周期
- CP.B 应该接收 10,000 的 1/4 -> 2500 个周期
- 将保留周期数乘以保留cpu核心数量
- CP.A 应收到 7500 个周期的 25%
- CP.B 应收到 2500 个周期的 25%
这些限制受到Job Objects的约束，当一个进程（代码包）被激活时，它被分配给一个设置了这些限制的作业，只要该进程消耗的周期多于设置的限制作业，线程被抢占，另一个进程线程被调度到核心。在代码中，他们建议 10000 represents all available cores 但正确的是 number of processor cycles that the threads in a job object can use during each scheduling interval。在一个Job中，10000个cycle是每个job调度的间隔，这个Job中调度一个线程，会消耗这个调度的x个cycles，如果你预留4核，就只消耗这10000个cycles。
确切的逻辑在这段代码中：
double shares = fractionOfSp * Constants::JobObjectCpuCyclesNumber;
shares = shares * (numCoresAllocated / max(numAvailableCores_, systemCpuCores_));
rg.CpuShares = static_cast<uint>(shares);
//fractionOfSp -> Fraction of a Service Package
// - A service package represents 100% (Like a Pizza) of reserved core capacity
// - Each Code Package will have one or more fraction (A slice of the pizza)
//Constants::JobObjectCpuCyclesNumber -> is a constant for 10000 cycles
//numCoresAllocated -> How many cores you assigned to a service package
一些技巧：
- 预留核心的数量也会影响结果，您必须至少预留 0.01% 的核心才能生效。
- 份额基于保留给服务包的 CPU 个内核，而不是节点中所有可用的 CPU 个内核，如果您的节点有 4 个内核，您将 1 个内核保留给服务包，这意味着您每个代码包共享 25% 的节点容量。
- 如果某些代码包的份额为零或没有份额，则所有代码包将具有相同的分数，即使您指定任何值也是如此。
- 在 linux 上，它使用 CpuQuota
- 一个作业最大循环次数为10k
如果您需要更多信息，请查看源代码here
PS: 把这些数字算得有点头晕了，以后可能会再复习一下！
我有 2 个服务结构应用程序 (sln) 和 3 个服务（3 个代码包）。我想以最大 CPU 百分比的 40% 20% 20% 分配它们，而不考虑核心，即对 CPU 核心的数量没有限制（当前机器是 4 核心逻辑）。根据以上 content/blog，如果我指定 CpuShares = 512、CpuShares = 256 和 CpuShares = 256，那么它应该占 40%、20%、20% 的最大值 CPU。然而，情况并非如此，它只允许各自服务的最大 CPU 使用量的 5%、2% 和 2%。通过阅读此 post (https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-resource-governance) 我认为 1024 是 CpuShares 的默认值（最大值），经过大量尝试和错误后，如果我们应用任何大于此的值，我最终得出 CpuShares 的值 10,000，我们会在服务资源管理器中收到错误消息，说 CpuShare 的参数无效。 所以考虑到 10,000 = 100% CPU 允许使用。我在测试中将上面的 CPU 共享值修改为 CpuShares = 4000、CpuShares = 2000 和 CpuShares = 2000 我可以看到最大 CPU 百分比使用率，其中 40% 20% 20%（不是精确的 5% 方差).所以问题是我无法在任何文档中找到 10,000 = 100% CPU 使用值。所以我想确认这是否正确，如果不正确，我该如何将服务或代码包限制为特定百分比。请帮忙解决这个问题
关于 SF 中服务资源治理的一个常见误解是，它是为您的服务保留和隔离的资源容量，就像它在 docker 容器上一样，但事实并非如此。
这些指标只是保持集群中服务平衡的软限制，并不意味着它们专门为您的服务保留，如果没有设置限制，其他服务可以并且将消耗这些资源。
For resource limit enforcement to work, all code packages within a service package should have memory limits specified.
指标是在集群中找到适当的服务平衡并将服务放置在具有可用资源的节点中的措施，因此假设您有服务 A、B 和 C，并且每个服务都有特定数量的资源需求, 比方说Memory，这是一个容易理解的值，A=1000MB，B=512MB，C=512MB，a节点有2GB内存，这些可以放在同一个节点，假设服务C需要1000MB，当需要激活服务 C 时，它会避开激活 A 和 B 的同一个节点，因为它没有能力在那里 运行，即使这些服务没有消耗所有请求的资源，另一个将选举节点。
来自docs：
The Service Fabric runtime currently does not provide reservation for resources. When a process or a container is opened, the runtime sets the resource limits to the loads that were defined at creation time. Furthermore, the runtime rejects the opening of new service packages that are available when resources are exceeded.
关于您关于股份的主要问题：
相同的文档描述了份额是保留的 CPU 核心保留给服务包的一部分，该服务包在该节点上激活的所有代码包之间分配，如果您为每个代码包定义份额，相加为总和，每人获得一定比例的份额。
这些股份是如何控制的？
Keep in mind the below are not officially documented anywhere and I might be wrong in some aspects, I've got this information from the source code and I might have missed some details
假设激活了包含代码包 A 和 B 的服务包，并进行以下份额拆分：
- 代码包A (CP.A) = 1500股
- 代码包B (CP.B) = 500股
顺丰将：
- 确定为服务包预留的CPU核心容量：
- 容量将是CPU核心预留容量（%）/总可用容量
- 4 核 cpu: 1 cpu 保留核心 = 25%
- 从代码包中获取所有份额并对它们的值求和以确定应代表 100% 的保留 (25%) 容量的份额
- 1500 + 500 = 2000 总股数
- CP.A 应该得到 4 的 3 个分数
- CP.B 应该得到 1 的 4
- 将份额分数转换为 CPU 工作周期（请参阅下文原因）
- CP.A 应该收到 10,000 的 3/4 -> 7500 个周期
- CP.B 应该接收 10,000 的 1/4 -> 2500 个周期
- 将保留周期数乘以保留cpu核心数量
- CP.A 应收到 7500 个周期的 25%
- CP.B 应收到 2500 个周期的 25%
这些限制受到Job Objects的约束，当一个进程（代码包）被激活时，它被分配给一个设置了这些限制的作业，只要该进程消耗的周期多于设置的限制作业，线程被抢占，另一个进程线程被调度到核心。在代码中，他们建议 10000 represents all available cores 但正确的是 number of processor cycles that the threads in a job object can use during each scheduling interval。在一个Job中，10000个cycle是每个job调度的间隔，这个Job中调度一个线程，会消耗这个调度的x个cycles，如果你预留4核，就只消耗这10000个cycles。
确切的逻辑在这段代码中：
double shares = fractionOfSp * Constants::JobObjectCpuCyclesNumber;
shares = shares * (numCoresAllocated / max(numAvailableCores_, systemCpuCores_));
rg.CpuShares = static_cast<uint>(shares);
//fractionOfSp -> Fraction of a Service Package
// - A service package represents 100% (Like a Pizza) of reserved core capacity
// - Each Code Package will have one or more fraction (A slice of the pizza)
//Constants::JobObjectCpuCyclesNumber -> is a constant for 10000 cycles
//numCoresAllocated -> How many cores you assigned to a service package
一些技巧：
- 预留核心的数量也会影响结果，您必须至少预留 0.01% 的核心才能生效。
- 份额基于保留给服务包的 CPU 个内核，而不是节点中所有可用的 CPU 个内核，如果您的节点有 4 个内核，您将 1 个内核保留给服务包，这意味着您每个代码包共享 25% 的节点容量。
- 如果某些代码包的份额为零或没有份额，则所有代码包将具有相同的分数，即使您指定任何值也是如此。
- 在 linux 上，它使用 CpuQuota
- 一个作业最大循环次数为10k
如果您需要更多信息，请查看源代码here
PS: 把这些数字算得有点头晕了，以后可能会再复习一下！