原文地址
https://blog.csdn.net/directionofear/article/details/8033506
如果Web应用程序经常遇到的问题按频率排名的话，我觉得
第一名unhandled exception
第二名high memory
第三名high cpu
这篇文章介绍web应用程序中cpu使用率过高问题相应的数据收集方式和调试问题的方法。
对ASP.NET Web应用程序CPU使用率过高的问题，从宏观上分分类，大概就这么几种情况，
大量请求
过多循环
GC频繁
数据收集
收集性能计数
通过以下命令行创建性能计数信息，该命令的意思是在系统性能计数器里面添加以下性能计数分类中的所有计数器，生成的日志大小最大为500M，达到该上限计数会停止，采样时间间隔为15秒，生成的日志存放在c:PerfLogPerf-15Sec.blg文件中。
Processor
Memory
Process
Asp.NET
ASP.NETApplications
.NET CLRExceptions
.NET CLRMemory
.NET CLRLoading
logman.execreate counter Perf-15Sec -f bincirc -max 500 -c "Processor(*)*""Memory*" "Process(*)*" "ASP.Net(*)*" "ASP.Net Applications(*)*" ".NET CLRExceptions(*)*" ".NET CLR Memory(*)*" ".NET CLRLoading(*)*" -si 00:00:15 -o C:PerfLogPerf-15Sec.blg
重现该问题前通过如下命令开始计数，
logman.exestart Perf-15Sec
重现问题后通过如下计数停止计数。
logman.exe stop Perf-15Sec
收集Full User Dump
收集性能计数能够从统计信息的角度对问题进行大概的定位，如果要查看程序内部逻辑，需要收集user dump，通过调试器查看程序详细信息。
收集dump的工具较多，对于high cpu的问题可以选择以下几种，其中Procdump是专门针对high cpu问题而设计，命令和节奏控制比较简单，推荐使用。
Procdump
下载地址
http://technet.microsoft.com/en-us/sysinternals/dd996900.aspx
在命令行里面运行以下命令，意思是当目标进程 w3wp的CPU使用率高于80%连续超过10秒钟的时候，连续收集三个dump到目标路径c:dump目录下。参数需要根据需要自行调整。
procdump -c 80 -s 10 -n 3 -o w3wpc:dump
Debug Diag
下载地址
http://www.microsoft.com/en-us/download/details.aspx?id=26798
DebugDiag有图形界面，可以配置类似的参数规则来抓取不同类型的dump。比如抓进程高cpu使用率的情况。
添加一个performnce规则，按照cpu的performance counter来添加相应的参数。（可以添加多种条件）
Adplus
Adplus包含在windbg安装包中，
下载地址
http://www.microsoft.com/en-us/download/details.aspx?id=8279
在问题发生的时候，打开命令行执行以下命令，
adplus -hang -pnw3wp.exe -quiet
问题调试
调试high cpu的问题就是要弄清楚cpu时间都花在了什么地方。CPU使用率就是一个统计数据，在采样时间内cpu忙的时间所占的百分比。
如何查看cpu时间具体花在了什么地方？
首先我们要弄清楚是哪个或者哪几个进程占用了cpu的处理时间。我们看到机器的cpu使用率偏高，一般都是注意到机器整体的使用率，这个时候性能计数可以帮助我们定位high cpu的进程都有哪些。
打开日志查看process/processortime对于各个进程不同数值，就可以看出来在特定时间哪个进程在占用cpu资源。
确定了进程后，要看进程中到底在做什么。我们研究的是asp.net web应用程序，这里假设发现w3wp进程占用了大量的cpu资源。
接下来我们要搞清楚，我们的cpu资源使用大概落在我们之前分类的那一种或者几种类型中。
大量请求
请求过多的情况一般表现为
大量工作线程在运行
Queue 中存在未处理的请求
线程上消耗的时间比较平均
通过!threadpool命令查看有多少个请求在queue中等待，多少个工作线程在运行，多少个空闲，当前的CPU占用率为多少，这里要注意这个CPU占用率是当前计算机整体的占用率，不针对当前进程。
0:000> .load psscor2
0:000> !threadpool
Work Request in Queue: 129
--------------------------------------
Number of Timers: 56
--------------------------------------
CPU utilization 99%
--------------------------------------
Worker Thread: Total: 49 Running: 24 Idle: 25MaxLimit: 400 MinLimit: 4
Completion Port Thread:Total: 1 Free: 1 MaxFree: 8 CurrentLimit: 0 MaxLimit: 400 MinLimit: 4
通过!runaway命令来查看各个线程消耗CPU时间的情况。
0:000> !runaway
User Mode Time
Thread Time
26:2bc 0 days 0:00:23.781
14:162c 0 days 0:00:22.562
31:1458 0 days 0:00:22.328
25:8c4 0 days 0:00:21.984
13:1708 0 days 0:00:21.937
38:b44 0 days 0:00:21.781
27:eec 0 days 0:00:21.734
34:e6c 0 days 0:00:21.328
20:70c 0 days 0:00:20.890
53:3c8 0 days 0:00:20.093
15:4bc 0 days 0:00:19.578
18:16a0 0 days 0:00:19.531
19:ef8 0 days 0:00:18.937
58:fd4 0 days 0:00:17.296
63:11b0 0 days 0:00:15.843
17:be4 0 days 0:00:15.484
64:15c0 0 days 0:00:14.984
65:c30 0 days 0:00:14.875
70:1058 0 days 0:00:14.031
73:150 0 days 0:00:13.609
66:708 0 days 0:00:13.593
69:f80 0 days 0:00:13.359
71:174c 0 days 0:00:13.171
68:bc0 0 days 0:00:12.796
可以通过以下命令来查看managed线程的当前调用栈信息。
~*e!clrstack
这种情况在压力测试时，或者网站请求负载平衡出现问题的时，或者业务量较大的时段有可能发生。在这种情况下通过更改代码来提升性能可能有些得不偿失了，更实际一点的建议是scale up（提升机器硬件性能）或者scaleout（扩展机器将请求分流）。
过多循环
无限循环或过多循环表现为
工作线程不多或者大多在等待
特定线程时间消耗超长
为了确定问题我们一般会抓多个dump文件，中间存在一定时间间隔，从十几秒到几分钟，基于high CPU持续时间而定。
测试程序
protected void Page_Load(object sender, EventArgs e)
{
System.Diagnostics.PerformanceCounter counter = new System.Diagnostics.PerformanceCounter();
counter.CategoryName = "Processor";
counter.CounterName = "% Processor Time";
counter.InstanceName = "_Total";
while (true)
{
while (counter.NextValue() < 70)
;
}
}
第一个dump中的cpu使用相关数据，
0:014> !runaway
User Mode Time
Thread Time
17:10f8 0 days 0:01:16.268
12:c64 0 days 0:00:07.659
7:908 0 days 0:00:00.109
23:a6c 0 days 0:00:00.015
9:175c 0 days 0:00:00.015
...
2:528 0 days 0:00:00.000
0:014> .time
Debug session time: Sat Sep 29 21:33:09.341 2012 (UTC + 8:00)
System Uptime: 6 days 22:15:37.061
Process Uptime: 0 days 0:04:56.007
Kernel time: 0 days 0:00:26.223
User time: 0 days 0:01:24.100
0:017> !clrstack
OS Thread Id: 0x10f8 (17)
Child-SP RetAddr Call Site
00000079fda8dc50 000007fe99ff648d Microsoft.Win32.RegistryKey.InternalGetValue(System.String, System.Object, Boolean, Boolean)
00000079fda8dcf0 000007fe9872fa76 Microsoft.Win32.RegistryKey.GetValue(System.String)
00000079fda8dd40 000007fe9872ec05 System.Diagnostics.PerformanceMonitor.GetData(System.String)
00000079fda8ddc0 000007fe9872ca17 System.Diagnostics.PerformanceCounterLib.GetPerformanceData(System.String)
00000079fda8de20 000007fe9872c8d2 System.Diagnostics.PerformanceCounterLib.GetCategorySample(System.String)
00000079fda8de70 000007fe986b59a4 System.Diagnostics.PerformanceCounterLib.GetCategorySample(System.String, System.String)
00000079fda8deb0 000007fe986b52c1 System.Diagnostics.PerformanceCounter.NextSample()
00000079fda8df90 000007fe3d070a76 System.Diagnostics.PerformanceCounter.NextValue()
00000079fda8e180 000007fe3d0d0f39 ASP.cpu70_aspx.Page_Load(System.Object, System.EventArgs)
00000079fda8e1d0 000007fe97399f8a System.Web.Util.CalliHelper.EventArgFunctionCaller(IntPtr, System.Object, System.Object, System.EventArgs)
00000079fda8e200 000007fe97390744 System.Web.Util.CalliEventHandlerDelegateProxy.Callback(System.Object, System.EventArgs)
00000079fda8e230 000007fe973907a2 System.Web.UI.Control.OnLoad(System.EventArgs)
...
00000079fda8f660 000007fe9c8cb31b DomainNeutralILStubClass.IL_STUB(Int64, Int64, Int64, Int32)
第二个dump中cpu使用相关数据，
0:014> !runaway
User Mode Time
Thread Time
17:10f8 0 days 0:02:14.706
12:c64 0 days 0:00:13.665
7:908 0 days 0:00:00.109
9:175c 0 days 0:00:00.015
...
1:1020 0 days 0:00:00.000
0:017> .time
Debug session time: Sat Sep 29 21:35:58.423 2012 (UTC + 8:00)
System Uptime: 6 days 22:18:26.143
Process Uptime: 0 days 0:07:45.089
Kernel time: 0 days 0:00:46.472
User time: 0 days 0:02:28.559
0:017> !clrstack
OS Thread Id: 0x10f8 (17)
Child-SP RetAddr Call Site
00000079fda8db20 000007fe9a9ee566 DomainNeutralILStubClass.IL_STUB(Microsoft.Win32.SafeHandles.SafeRegistryHandle, System.String, Int32[], Int32 ByRef, Byte[], Int32 ByRef)
00000079fda8dc50 000007fe99ff648d Microsoft.Win32.RegistryKey.InternalGetValue(System.String, System.Object, Boolean, Boolean)
00000079fda8dcf0 000007fe9872fa76 Microsoft.Win32.RegistryKey.GetValue(System.String)
00000079fda8dd40 000007fe9872ec05 System.Diagnostics.PerformanceMonitor.GetData(System.String)
00000079fda8ddc0 000007fe9872ca17 System.Diagnostics.PerformanceCounterLib.GetPerformanceData(System.String)
00000079fda8de20 000007fe9872c8d2 System.Diagnostics.PerformanceCounterLib.GetCategorySample(System.String)
00000079fda8de70 000007fe986b59a4 System.Diagnostics.PerformanceCounterLib.GetCategorySample(System.String, System.String)
00000079fda8deb0 000007fe986b52c1 System.Diagnostics.PerformanceCounter.NextSample()
00000079fda8df90 000007fe3d070a76 System.Diagnostics.PerformanceCounter.NextValue()
00000079fda8e180 000007fe3d0d0f39 ASP.cpu70_aspx.Page_Load(System.Object, System.EventArgs)
00000079fda8e1d0 000007fe97399f8a System.Web.Util.CalliHelper.EventArgFunctionCaller(IntPtr, System.Object, System.Object, System.EventArgs)
...
00000079fda8f660 000007fe9c8cb31b DomainNeutralILStubClass.IL_STUB(Int64, Int64, Int64, Int32)
根据抓取dump的时间来看(.time命令输出)，
两个dump中该进程用户模式下消耗的cpu时间为2:28.559 - 1:24.110 = 1:04.449
两个dump中17号线程消耗cpu时间为2:14.706 - 1:16.268 = 0:58.438
由此可以看到在该段时间内绝大多数的cpu时间是17号线程消耗的。因此我们可以把关注点放在17号线程上。
对比两次调用栈信息可以看到都是在cpu70这个页面Page_Load方法中。
GC频繁
GC频繁的情况的表现
GC线程消耗时间超长
GC正在运行
内存分配速率高
测试程序
<%@ Page Language="C#" AutoEventWireup="true" Inherits="System.Web.UI.Page" %>
<script runat="server">
protected void btnStart_Click(object sender, EventArgs e)
{
int number =0;
if (int.TryParse(txtNumber.Text, out number))
{
string dates = "<Dates>";
for (int i = 0; i < number; i++)
{
for (int j = 0; j < i; j++)
{
DateTime dt = DateTime.Now.Add(new TimeSpan(j, 0, 0, 0));
dates += "<Date><Month>" + dt.Month + "</Month><Day>" + dt.Day + "</Day><DayOfWeek>" + dt.DayOfWeek + "</DayOfWeek><Date>";
dates += "<Date><Month>" + dt.Month + "</Month><Day>" + dt.Day + "</Day><DayOfWeek>" + dt.DayOfWeek + "</DayOfWeek><Date></br>";
}
dates += "</Dates>";
}
Response.Write(dates);
}
}
</script>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<title></title>
</head>
<body>
<form id="form1" runat="server">
<div>
<asp:TextBox ID="txtNumber" runat="server"/>
<asp:Button ID="btnStart" Text="Start" OnClick="btnStart_Click" runat="server"/>
</div>
</form>
</body>
</html>
对于该问题初步的定位可以参照以下性能计数器，
.NET CLR Memory/% Time in GC - 从上次GC结束到现在为止，GC占用的时间比例。比如从上次GC到现在已经过了1000个时钟周期，其中300个花在了当前GC上，那就是30%
.NET CLR MemoryAllocated Bytes/sec - CLR每秒分配内存数值
# Gen 0 Collections - 第0代GC的次数
#Gen 1 Collections - 第1代GC的次数
#Gen 2 Collections - 第二代GC的次数
Large Object Heap Size - 大对象堆的大小
要关注这些性能计数的点
%Time in GC值在CPU占用率高的时段的大小
AllocatedBytes/sec分配内存速度
#Gen2 Collections的数值大小
Gen0 ： Gen 1 ： Gen 2的比例，理想比例为100：10：1
LargeObject Heap值的大小
通过查看性能计数我们怀疑这次问题可能与GC有关，接下来查看dump文件。
先查看GC线程在做什么(这里服务器默认采用server mode，每个cpu核对应一个gc线程)
以下是一个GC没有做事的状态作为参照。
0:013> kL
Child-SP RetAddr Call Site
0000009d`d308f628 000007fe`bea310ea ntdll!ZwWaitForSingleObject+0xa
0000009d`d308f630 000007fe`9a3bd220 KERNELBASE!WaitForSingleObjectEx+0x92
0000009d`d308f6d0 000007fe`9a3bd10f mscorwks!CLREvent::WaitEx+0x174
0000009d`d308f720 000007fe`9a9cb437 mscorwks!CLREvent::WaitEx+0x63
0000009d`d308f7d0 000007fe`9a46d4d3 mscorwks!SVR::gc_heap::gc_thread_function+0x47
0000009d`d308f830 000007fe`c0e6167e mscorwks!SVR::gc_heap::gc_thread_stub+0x93
0000009d`d308f880 000007fe`c1a4c3f1 KERNEL32!BaseThreadInitThunk+0x1a
0000009d`d308f8b0 00000000`00000000 ntdll!RtlUserThreadStart+0x1d
先查看那个线程是gc线程
0:013> !threads -special
ThreadCount: 8
UnstartedThread: 0
BackgroundThread: 8
PendingThread: 0
DeadThread: 0
Hosted Runtime: no
PreEmptive Lock
ID OSID ThreadOBJ State GC GC Alloc Context Domain Count APT Exception
7 1 1534 0000009dd2bfd260 8220 Enabled 0000000000000000 0000009dd2be2c90 0 Ukn
14 2 1764 0000009dd2c02ef0 b220 Enabled 0000000000000000 0000009dd2be2c90 0 MTA
11 3 5dc 0000009dd2c33bc0 880a220 Enabled 0000000000000000 0000009dd2be2c90 0 MTA
16 4 1048 0000009dd2c54e30 80a220 Enabled 0000000000000000 0000009dd2be2c90 0 MTA
17 5 7f4 0000009dd2c55c80 1220 Enabled 0000000000000000 0000009dd2be2c90 0 Ukn
18 6 1448 0000009dd2c9c1a0 180b220 Enabled 0000000000000000 0000009dd2c56ba0 1 MTA
9 7 768 0000009dd3b56150 220 Enabled 0000000000000000 0000009dd2be2c90 0 Ukn
19 8 1074 0000009dd19066d0 180b220 Enabled 0000000000000000 0000009dd2be2c90 0 MTA
OSID Special thread type
10 cc0 Gate
11 5dc IOCompletion
12 1344 DbgHelper
13 107c GC SuspendEE
14 1764 Finalizer
16 1048 Timer
17 7f4 ADUnloadHelper
18 1448 ThreadpoolWorker
19 1074 ThreadpoolWorker
GC13号线程调用栈，与不做事的时候调用栈不一样，说明正在GC。
0:013> k
Child-SP RetAddr Call Site
0000009d`d308f5a0 000007fe`9a44dfed mscorwks!SVR::gc_heap::plan_phase+0x499
0000009d`d308f700 000007fe`9a968d35 mscorwks!SVR::gc_heap::gc1+0x6d
0000009d`d308f760 000007fe`9a9cb46f mscorwks!SVR::gc_heap::garbage_collect+0x2f5
0000009d`d308f7d0 000007fe`9a46d4d3 mscorwks!SVR::gc_heap::gc_thread_function+0x7f
0000009d`d308f830 000007fe`c0e6167e mscorwks!SVR::gc_heap::gc_thread_stub+0x93
0000009d`d308f880 000007fe`c1a4c3f1 KERNEL32!BaseThreadInitThunk+0x1a
0000009d`d308f8b0 00000000`00000000 ntdll!RtlUserThreadStart+0x1d
接下来我们要看为什么会这么频繁的发生GC。
先看看目前运行的请求都有哪些，发现只有18号线程(这里我们为了演示只用了一个请求，现实情况应该会有较多请求)
0:013> !aspxpages
HttpContext Timeout Completed Running ThreadId ReturnCode Verb RequestPath+QueryString
0x0000009d800ed140 19200 Sec no 652 Sec 18 200 POST /high_gc.aspx
Total 1 HttpContext objects
查看一个18号线程，原来该线程在尝试在大对象对上分配内存而触发的了GC。
0:018> !dumpstack
OS Thread Id: 0x1448 (18)
Child-SP RetAddr Call Site
0000009dd3e2d4b8 000007febea3152c ntdll!ZwSetEvent+0xa
0000009dd3e2d4c0 000007fe9a770218 KERNELBASE!SetEvent+0xc
0000009dd3e2d4f0 000007fe9a689cac mscorwks!CLREvent::Set+0x128
0000009dd3e2d570 000007fe9a81362c mscorwks!SVR::GCHeap::GarbageCollectGeneration+0x1fc
0000009dd3e2d5d0 000007fe9a332ae2 mscorwks!SVR::gc_heap::try_allocate_more_space+0x1ac
0000009dd3e2d6c0 000007fe9a35df7f mscorwks!SVR::gc_heap::allocate_more_space+0x32
0000009dd3e2d710 000007fe9a40baf8 mscorwks!SVR::gc_heap::allocate_large_object+0x5f
0000009dd3e2d780 000007fe9a40be0e mscorwks!SVR::GCHeap::Alloc+0x198
0000009dd3e2d7c0 000007fe9a89b143 mscorwks!SlowAllocateString+0x7e
0000009dd3e2d840 000007fe97de9566 mscorwks!FramedAllocateString+0xd3
0000009dd3e2da00 000007fe3ac9130d mscorlib_ni!System.String.ConcatArray(System.String[], Int32)+0x16
0000009dd3e2da60 000007fe89b592b3 App_Web_brwfhign!ASP.high_gc_aspx.btnStart_Click(System.Object, System.EventArgs)+0x53d
0000009dd3e2dbd0 000007fe89b5978c System_Web_ni!System.Web.UI.WebControls.Button.OnClick(System.EventArgs)+0x73
0000009dd3e2dc10 000007fe892f3a2d System_Web_ni!System.Web.UI.WebControls.Button.RaisePostBackEvent(System.String)+0x8c
…
0000009dd3e2f5c0 000007fec0e6167e mscorwks!Thread::intermediateThreadProc+0x78
0000009dd3e2f790 000007fec1a4c3f1 KERNEL32!BaseThreadInitThunk+0x1a
0000009dd3e2f7c0 0000000000000000 ntdll!RtlUserThreadStart+0x1d
通过调用栈来看应该是在分配内存给string类型的数据，请求还在进行中，该string应该还在线程栈上，接下来查看该线程栈找到该对象，
0:018> !dso
OS Thread Id: 0x1448 (18)
RSP/REG Object Name
0000009dd3e2d618 0000009d8000b5d8 System.RuntimeType
0000009dd3e2d628 0000009d8000b5d8 System.RuntimeType
0000009dd3e2d630 0000009d800aea00 System.RuntimeType
0000009dd3e2d658 0000009d8000b5d8 System.RuntimeType
0000009dd3e2d7c8 0000009d800efab0 System.Web.UI.WebControls.Button
0000009dd3e2d7e0 0000009d8000b458 System.Reflection.Module
0000009dd3e2d7f8 0000009d80009648 System.RuntimeType
0000009dd3e2d8b0 0000009d800f5178 System.RuntimeType
0000009dd3e2d938 0000009d800efab0 System.Web.UI.WebControls.Button
0000009dd3e2d958 0000009d800baee0 System.Web.HttpApplication+PipelineStepManager
0000009dd3e2d9c0 0000009d800baee0 System.Web.HttpApplication+PipelineStepManager
0000009dd3e2d9c8 0000009d800ed140 System.Web.HttpContext
0000009dd3e2da20 0000009d800ed140 System.Web.HttpContext
0000009dd3e2da48 0000009d800efab0 System.Web.UI.WebControls.Button
0000009dd3e2da98 0000009dc04f2db0 System.String
0000009dd3e2dac0 0000009dc04f2db0 System.String
0000009dd3e2db28 0000009d8012ae88 System.Object[] (System.Object[])
0000009dd3e2db38 0000009d8012ae88 System.Object[] (System.Object[])
0000009dd3e2db48 0000009d8012ae88 System.Object[] (System.Object[])
0000009dd3e2db58 0000009dc04f2db0 System.String
0000009dd3e2db90 0000009dc03fbfa0 System.String
随便挑了一个string都1M左右，大于85,000byte就是大对象。
0:018> !objsize 0000009dc04f2db0
sizeof(0000009dc04f2db0) = 1,011,336 ( 0xf6e88) bytes (System.String)
通过!do命令把这个字符串输出+回头查看代码逻辑=解决问题
0:018> !do 0000009dc04f2db0
Name: System.String
MethodTable: 000007fe97f17c20
EEClass: 000007fe97b1e550
Size: 1011330(0xf6e82) bytes
GC Generation: 3
(C:WindowsassemblyGAC_64mscorlib2.0.0.0__b77a5c561934e089mscorlib.dll)
String: <Dates></Dates><Date><Month>9</Month><Day>29</Day><DayOfWeek>Saturday</DayOfWeek>……………省略1M字符串