iis worker 进程时间过长

Question

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

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

这个穿什么：

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

当我在 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

请考虑以下场景：

1. 为跟踪分析准备程序，但不要立即启动它
2. 准备一个导致“挂起”的操作
3. 开始分析并执行操作。如果您在页面打开之前立即开始分析并在之后立即停止，则快照将包含更少的来自应用程序内部其他执行的“噪音”；
4. 获取快照

快照将显示经过时间的堆栈跟踪。

但是，如果您不知道挂起情况，您可以根据 HttpResponse time 性能计数器捕获内存转储。您可以使用 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 进行故障排除。这两种工具都可以被动监控，并在超过指定时间的请求上触发日志收集。