.Net 调式案例—实验4 高CPU（High CPU）回顾

原文地址：http://blog.csdn.net/directionofear/article/details/8033506

如果Web应用程序经常遇到的问题按频率排名的话，我觉得

第一名unhandled exception

第二名high memory

第三名high cpu

这篇文章介绍web应用程序中cpu使用率过高问题相应的数据收集方式和调试问题的方法。

对ASP.NET Web应用程序CPU使用率过高的问题，从宏观上分分类，大概就这么几种情况，

  1. 大量请求
  2. 过多循环
  3. GC频繁

数据收集

收集性能计数

通过以下命令行创建性能计数信息，该命令的意思是在系统性能计数器里面添加以下性能计数分类中的所有计数器，生成的日志大小最大为500M，达到该上限计数会停止，采样时间间隔为15秒，生成的日志存放在c:\PerfLog\Perf-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:\PerfLog\Perf-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 Memory\Allocated 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:\Windows\assembly\GAC_64\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
String: <Dates></Dates><Date><Month>9</Month><Day>29</Day><DayOfWeek>Saturday</DayOfWeek>……………省略1M字符串

时间： 2024-10-06 15:57:11

.Net 调式案例—实验4 高CPU（High CPU）回顾的相关文章

AB实验的高端玩法系列2 - 更敏感的AB实验, CUPED！

背景 AB实验可谓是互联网公司进行产品迭代增加用户粘性的大杀器.但人们对AB实验的应用往往只停留在开实验算P值,然后let it go...let it go ... 让我们把AB实验的结果简单的拆解成两个方面: \[P(实验结果显著) = P(统计检验显著|实验有效)× P(实验有效)\] 如果你的产品改进方案本来就没啥效果当然怎么开实验都没用,但如果方案有效,请不要让 statictical Hack 浪费一个优秀的idea 如果预期实验效果比较小,有哪些基础操作来增加实验显著性呢? 通常情

泛泰A820L (高通MSM8660 cpu) 3.4内核的CM10.1(Android 4.2.2) 测试版

欢迎关注泛泰非盈利专业第三方开发团队 VegaDevTeam  (本team 由 syhost suky zhaochengw(z大) xuefy(大星星) tenfar(R大师) loogeo crazyi(天下无雪) windxixi(雪狐) wangsai008 组成) 感谢: tenfar(R大师),zhaochengw(z大),xuefy(大星星),suky,wzhy90 特别说明: 此版本仅为测试版, 用于测试反馈bug(本人已经测试将近10天),  因为3.4内核的MSM8660

关于linux系统CPU篇---&gt;CPU使用率升高

1.CPU使用率为单位时间内CPU使用情况的统计,以百分比的方式展示. LINUX作为一个多任务操作系统,将每个CPU的时间划分为很短的时间片,再通过调度器轮流分配给各个任务使用,因此造成多任务同时运行的错觉 2.如何查看CPU使用率? TOP和PS是最常用的性能分析工具.TOP显示了系统总体的CPU和内存使用情况,以及各个进程的资源使用情况 PS则只显示了每个进程的资源使用情况 pidstat是专门分析每个进程的CPU使用情况的工具 TOP输出: # 默认每 3 秒刷新一次$ toptop -

从Java视角理解CPU缓存(CPU Cache)

从Java视角理解系统结构连载, 关注我的微博(链接)了解最新动态众所周知, CPU是计算机的大脑, 它负责执行程序的指令; 内存负责存数据, 包括程序自身数据. 同样大家都知道, 内存比CPU慢很多. 其实在30年前, CPU的频率和内存总线的频率在同一个级别, 访问内存只比访问CPU寄存器慢一点儿. 由于内存的发展都到技术及成本的限制, 现在获取内存中的一条数据大概需要200多个CPU周期(CPU cycles), 而CPU寄存器一般情况下1个CPU周期就够了. CPU缓存 网页浏览器为了加

Linux下区分物理CPU、逻辑CPU和CPU核数

判断依据: 一个物理封装的CPU(通过physical id区分判断)可以有多个核(通过core id区分判断). 而每个核可以有多个逻辑cpu(通过processor区分判断). 一个核通过多个逻辑cpu实现这个核自己的超线程技术. cpu cores 条目包含位于相同物理封装中的内核数量. siblings 条目列出了位于相同物理封装中的逻辑处理器的数量. // proc文件用processor做索引,是因为processor是拥有其下所列所有信息的最小单位.方便查看细化信息. //例如如果

c语言设置cpu affinity (设置程序需要使用的cpu内核) cpu mask

最近打算写个小程序, 需要控制使用的是哪个 cpu 内核,所以做了一些调查, 整理一下分享给大家. ps: 因为毕业季很久没有写博客了, 以后继续. 顺便鄙视一下那些转载不声明出处的, by watkins.song pps: 最近有了个新的id, 因为在Oracle, wei.x.song, 不知到以后用哪个id比较酷一点 主要参考: http://www.gnu.org/software/libc/manual/html_node/CPU-Affinity.html/ http://stac

NGINX源码剖析 之 CPU绑定(CPU亲和性)

作者:邹祁峰 邮箱:[email protected] 博客:http://blog.csdn.net/qifengzou 日期:2014.06.12 18:44 转载请注明来自"祁峰"的CSDN博客 1 引言   非统一内存访问(NUMA)是一种用于多处理器的电脑记忆体设计,内存访问时间取决于处理器的内存位置. 在NUMA下,处理器访问它自己的本地存储器的速度比非本地存储器(存储器的地方到另一个处理器之间共享的处理器或存储器)快一些. 针对NUMA架构系统的特点,可以通过将进程/线程

[转]物理CPU、CPU核数、逻辑CPU、超线程

转自:http://wulc.me/2016/01/06/物理CPU.CPU核数.逻辑CPU.超线程/ 基本概念 物理CPU: 物理CPU就是插在主机上的真实的CPU硬件,在Linux下可以数不同的physical id 来确认主机的物理CPU个数. 核心数: 物理CPU下一层概念就是核心数,我们常常会听说多核处理器,其中的核指的就是核心数.在Linux下可以通过cores来确认主机的物理CPU的核心数. 逻辑CPU: 核心数下一层的概念是逻辑CPU,逻辑CPU跟超线程技术有联系,假如物理CPU

Windows系统CPU内存网络性能统计第四篇 CPU 多核CPU各核使用率C++

分享一下我老师大神的人工智能教程吧.零基础!通俗易懂!风趣幽默!还带黄段子!希望你也加入到我们人工智能的队伍中来!http://www.captainbed.net 转载请标明出处,原文地址:http://blog.csdn.net/morewindows/article/details/8678396 欢迎关注微博:http://weibo.com/MoreWindows Windows系统CPU内存网络性能统计第四篇 CPU多核CPU各核使用率 C++ http://blog.csdn.ne