IIS工作進程時間過去了很長

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

嘗試使用Failed Request Tracing或PerfView進行故障排除。這兩種工具都可以被動地進行監視，並在比指定時間更長的請求上觸發日誌收集。

Answer 2

爲了找出掛起的原因（關於瓶頸的準確結論），我建議您執行跟蹤性能分析會話（它會給出關於方法調用次數和持續時間的信息）。 但是，這是可能的，當你知道的竅門場景 = \

您可以找到有關這裏介紹方法的詳細信息： http://www.jetbrains.com/profiler/webhelp/Profiling_Guidelines__Choosing_the_Right_Profiling_Mode.html

請考慮以下情況：

1. 準備程序追蹤分析，但不要立即開始
2. 準備一個操作，導致'掛起'
3. 開始分析和執行操作。如果您在頁面打開之前立即開始分析並立即停止，則快照將包含來自應用程序內其他執行的較少「噪聲」;
4. 獲取快照

快照將顯示隨時間推移蹤跡。

但是，如果你不知道的竅門方案，你可以捕捉基於的HttpResponse時間性能計數器內存轉儲。您可以使用DebugDiag工具執行此操作：

1）運行DebugDiag工具。

2）單擊「添加規則...」;

3）在出現的對話框中，選擇性能規則類型;

4）選擇「HTTP響應時間」;

5）單擊「添加URL」按鈕;

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

然後你可以使用同步塊命令查看鏈！

這裏是一個很好的解釋：

Please explain !SyncBlk the windbg command