3

在分析应用程序（使用 dotTrace）时，我注意到一件非常奇怪的事情。我使用了“墙上时间”测量，理论上这应该意味着所有线程都会运行相同的时间。

但事实并非如此：某些线程（实际上是我最感兴趣的线程）显示的总时间比其他线程少 2 倍。例如，分析运行了 230 秒，大多数线程报告在线程中花费了 230 秒，但 5 个线程仅显示 100-110 秒。这些不是线程池线程，它们肯定是在分析开始之前创建和启动的。

这里发生了什么？

更新我将添加更多可能相关或不相关的信息。有问题的应用程序（它是一个游戏服务器）有大约 20-30 个持续运行的线程。大多数线程都遵循简单的模式：它们检查传入队列的工作，如果有的话就开始工作。thread func 的代码如下所示：

while(true){
    if(TryDequeueWork()){ // if queue is not empty
        DoWork();         // do whatever is was on top
    }else{
        m_WaitHandle.WaitOne(MaxTimeout); // m_WaitHandle gets signaled when work is added to queue
    }
}

显示奇怪时间的线程是这样的，除了它们服务于多个队列，像这样：

while(true){
    bool hasAnyWork=false;
    foreach(var queue in m_Queues){
        if(queue.TryDequeueWork()){
            hasAnyWork=true;
            DoWork();
        }
    }
    if(!hasAnyWork){ 
        m_WaitHandle.WaitOne(MaxTimeout); 
    }
}

奇怪的线程除了日志之外不做任何 IO。其他不奇怪的线程也进行日志记录。在分析器中报告等待 WaitHandle 所花费的时间；实际上，一些不奇怪的线程几乎把所有时间都花在等待上（因为它们从来没有任何工作）。

该应用程序在 8 核虚拟机（VPS 托管）上运行。我不知道那里使用什么物理处理器。

4

2 回答 2

1

你只能获得 100% 的挂墙时间，如果

  • 您的机器至少拥有与线程一样多的内核
  • 线程除了消耗 cpu 周期外什么都不做，并且永远不会被同步对象（如lock）或 I/O 请求阻塞。

两者都不太可能，很少有问题可以很好地扩展。 阿姆达尔定律是相关的。

于 2011-02-09T14:50:43.707 回答
1

也许他们在分析器完成之前完成了？

于 2011-02-09T14:31:22.440 回答