Question

我监控iis工作流程，发现很少有请求时间过去，

我使用未找到死锁的windbg转储w3wp.exe。

对此有何看法：

enter image description here

-------------------更新--------------------------- ---

当我在windbg中运行！runaway命令时，得到的结果如下，但似乎没问题。 14秒内线程的最长时间。

0:000> !runaway
 User Mode Time
  Thread       Time
  10:cc0       0 days 0:00:14.765
  11:3178      0 days 0:00:14.718
  13:288c      0 days 0:00:14.359
  12:11d4      0 days 0:00:14.203
  44:216c      0 days 0:00:09.781
  47:ac0       0 days 0:00:08.125
  50:3388      0 days 0:00:06.546
  31:21c4      0 days 0:00:06.484
  53:2a68      0 days 0:00:05.687
  21:e48       0 days 0:00:05.515
  51:2c78      0 days 0:00:05.281
  73:fd0       0 days 0:00:04.968
  52:2824      0 days 0:00:04.703
  77:26e0      0 days 0:00:04.437
  76:1bbc      0 days 0:00:04.343
  78:2fa4      0 days 0:00:04.250
  69:c6c       0 days 0:00:04.218
  68:dd0       0 days 0:00:04.078
  70:220c      0 days 0:00:04.015
  72:a2c       0 days 0:00:04.000
  74:15b0      0 days 0:00:03.875
  71:2984      0 days 0:00:03.781
  75:3784      0 days 0:00:03.640
  62:e3c       0 days 0:00:03.546
  65:1da0      0 days 0:00:03.406
  79:18f0      0 days 0:00:03.312
  64:1920      0 days 0:00:03.265
  63:32bc      0 days 0:00:03.218
  41:e70       0 days 0:00:03.015
  66:1148      0 days 0:00:02.921
  67:1398      0 days 0:00:02.453
  42:2180      0 days 0:00:02.296
  43:1c28      0 days 0:00:02.265
  33:1208      0 days 0:00:01.546
  46:3928      0 days 0:00:01.265
  45:2854      0 days 0:00:01.125
 114:34e4      0 days 0:00:00.875
  55:f4        0 days 0:00:00.796
  49:2e68      0 days 0:00:00.781
   6:2fb4      0 days 0:00:00.781
   4:3354      0 days 0:00:00.781
  32:3110      0 days 0:00:00.765
  60:2054      0 days 0:00:00.718
  56:18c4      0 days 0:00:00.703
  61:111c      0 days 0:00:00.656
  59:1cb0      0 days 0:00:00.625
  58:28d0      0 days 0:00:00.562
  99:14ac      0 days 0:00:00.500
  57:3078      0 days 0:00:00.437
  38:35fc      0 days 0:00:00.390
  82:2ebc      0 days 0:00:00.312
  26:38cc      0 days 0:00:00.312
  27:23a4      0 days 0:00:00.296
  85:e78       0 days 0:00:00.281
  28:35bc      0 days 0:00:00.281
  22:3284      0 days 0:00:00.281
  86:b7c       0 days 0:00:00.265
  29:888       0 days 0:00:00.265
  97:19c4      0 days 0:00:00.250
  96:e88       0 days 0:00:00.250
  23:3b08      0 days 0:00:00.234
  83:9b0       0 days 0:00:00.218
  88:13c8      0 days 0:00:00.187
 107:a0c       0 days 0:00:00.156
  14:90        0 days 0:00:00.156
   5:2ae4      0 days 0:00:00.140
  36:25cc      0 days 0:00:00.093
 115:35a0      0 days 0:00:00.078
  87:3b54      0 days 0:00:00.078
  84:10c0      0 days 0:00:00.078
  39:2454      0 days 0:00:00.062
  37:1644      0 days 0:00:00.046
   0:35c8      0 days 0:00:00.046
 109:940       0 days 0:00:00.031
 105:4a4       0 days 0:00:00.031
 104:14a4      0 days 0:00:00.031
 103:1c98      0 days 0:00:00.031
 100:2b88      0 days 0:00:00.031
  94:1b04      0 days 0:00:00.031
  92:363c      0 days 0:00:00.031
  89:e2c       0 days 0:00:00.031
  80:3660      0 days 0:00:00.031
  34:1bd4      0 days 0:00:00.031
  18:37fc      0 days 0:00:00.031
  17:1e30      0 days 0:00:00.031
 113:29a0      0 days 0:00:00.015
 112:8d0       0 days 0:00:00.015
 111:2074      0 days 0:00:00.015
 110:3a64      0 days 0:00:00.015
 108:e0c       0 days 0:00:00.015
 106:e14       0 days 0:00:00.015
 102:335c      0 days 0:00:00.015
 101:2270      0 days 0:00:00.015
  98:12fc      0 days 0:00:00.015
  95:2308      0 days 0:00:00.015
  93:39e0      0 days 0:00:00.015
  90:27e8      0 days 0:00:00.015
  48:2b60      0 days 0:00:00.015
  30:16c8      0 days 0:00:00.015
  24:38dc      0 days 0:00:00.015
  19:3b70      0 days 0:00:00.015
   1:12c8      0 days 0:00:00.015
  91:317c      0 days 0:00:00.000
  81:28c0      0 days 0:00:00.000
  54:28cc      0 days 0:00:00.000
  40:2bec      0 days 0:00:00.000
  35:19a0      0 days 0:00:00.000
  25:20c0      0 days 0:00:00.000
  20:2620      0 days 0:00:00.000
  16:2cdc      0 days 0:00:00.000
  15:3474      0 days 0:00:00.000
   9:3ab4      0 days 0:00:00.000
   8:2940      0 days 0:00:00.000
   7:2b14      0 days 0:00:00.000
   3:365c      0 days 0:00:00.000
   2:2278      0 days 0:00:00.000

Answer 1

为了找出挂起的原因（关于瓶颈的准确结论），我建议您执行跟踪性能分析会话（它会提供有关方法调用次数及其持续时间的信息）。 但是当您知道挂起方案 = \

时，这是可能的

您可以在此处找到有关分析方法的更多信息： http://www.jetbrains.com/profiler/webhelp/Profiling_Guidelines__Choosing_the_Right_Profiling_Mode.html

请考虑以下情况：

准备跟踪性能分析的程序，但不要立即启动
准备导致'hang'
开始分析并执行操作。如果您在打开页面之前立即开始分析并在之后立即停止，则快照将包含来自应用程序内其他执行的较少“噪音”;
获取快照

快照会显示堆栈跟踪的已用时间。

但是，如果您不知道挂起方案，则可以基于 HttpResponse时间 性能计数器捕获内存转储。您可以使用DebugDiag工具执行此操作：

1）运行DebugDiag工具。

2）点击“添加规则...”;

3）在出现的对话框中，选择性能规则类型;

4）选择“HTTP响应时间”;

5）点击“添加网址”按钮;

6）选择“使用ETW进行监控......”。指定需要很长时间加载和超时的页面的相对URL - 40秒。

7）添加转储目标。选择“Web应用程序池”类型，然后选择站点的应用程序池。

8）以10秒的间隔收集单独系列中的所有转储。这3个转储应该是完全用户转储。

有关收集“挂起转储”的更多详细信息，请查看以下帖子： http://blogs.msdn.com/b/debugdiag/archive/2013/03/15/debug-diagnostic-1-2-creating-a-rule-in-hang-mode-to-use-the-response-time-of-the-request-etw.aspx

然后您可以使用！syncblock 命令查看链。

这是一个很好的解释：

Please explain !SyncBlk the windbg command

Answer 2

尝试使用Failed Request Tracing或PerfView进行问题排查。这两个工具都可以被动监控，并在需要的时间超过指定时间的请求上触发日志收集。

iis工作流程时间过去很长时间

2 个答案: