1

我在一个小型集群上使用了一种负载均衡器，它能够在零持续时间的请求（工作节点立即满足的ti 请求）上实现>2000rps。但是，一旦请求停止为零持续时间并开始花费 1 毫秒，性能立即下降 > 10 倍。双向传输的数据是相同的，大小约为 2kb。这肯定与集群饱和或网络吞吐量无关，因为 200rps 的 1ms 请求是非常小的负载，而网络是 10Gbit。此外，负载均衡器和工作节点上的 CPU 负载只有 2-5%。

我想知道这是否与操作系统调度程序或操作系统网络堆栈的某些病态行为有关（对于非常短的交互，存在一些特殊情况行为）。

我该如何诊断原因？哪些 perfcounters 值得关注？使用什么工具或方法？

（以防有人简单地知道我的特定问题的答案，我说的是 MS HPC Server 2008 R2 的“WCF 代理”，在 Hyper-V 上的 Windows Server 2008 R2 上运行）

4

3 回答 3

1

您可以做的一件事是使用 ETW 跟踪来尝试了解在 WCF 作业运行时节点在做什么。在 HPC 服务器上，我有时会使用 clusrun xperf 来收集所有或特定节点上的跟踪信息。有许多工具可用于分析 ETW 跟踪，包括 xperf 本身。我没有使用 HPC SOA (WCF) 进行任何认真的工作，但我确实编写了一个简单的 WCF 光线跟踪器应用程序，然后使用 xperf 在几个节点上对其进行了分析。

于 2010-08-16T00:58:17.830 回答
1

原来这是一个完全与网络无关的问题，与 HPC Server 的调度机制的特性有关。我通过在 WCF 服务配置文件的 loadBalancing 部分将配置选项“serviceRequestPrefetchCount”调整为 0 解决了这个问题。

于 2010-08-16T09:05:12.247 回答
0

我假设有一些共享资源与某种锁定系统到位？锁定是瓶颈吗？不看系统很难猜到。

你有办法描述工人吗？他们大部分时间都花在什么上了，尤其是在快与慢的场景中？

于 2010-08-11T18:57:07.327 回答