CPU占用过高问题分析.docxVIP

1.1.2 CPU 占用过高问题定位过程1．问题描述200 人并发使用某服务器，使用中出现所有客户端卡死，服务器无法接收客户端任何请求。提供了一个线索：此时服务器CPU 利用率接近100%。2．定位分析这台服务器运行着ERP 系统，主要承载Web 服务器，根据客户提供的线索很可能是CPU利用率100%导致服务器繁忙，而不能及时响应所有客户端的请求，出现所有客户端“假死”现象，这是很常见的问题。往往很多非专业计算机人员遇到这种问题就重启一下Web 服务器或客户服务器，继续使用。这样既解决不了问题，又会丢失线索，而且问题还会重复出现。先看一下服务器计数器，计数器中显示“% Time in GC”为CPU 利用率90%，如图1-9所示。说明：一般 % Time in GC 10%，基本上就应该检查代码了，而这里达到90%。现象已经基本明确，是由于w3wp 中的GC 线程不断地在做垃圾回收工作，耗尽CPU 资源，导致服务器不能处理其他客户端客户发来的请求。到这里只是笼统的分析，还不能确定是什么问题，更不能做任何结论，要确定是什么导致GC 这么忙碌才是最终目的。一般涉及GC 问题都是服务端代码写法不正确导致的，找到代码并修改才是根本。下面就分析一下是哪句代码出的问题。这里使用WinDbg 工具从webserver 的进程中寻找线索。WinDbg 是微软内部用来调试操作系统bug 的一个工具，当然也能够调试应用程序软件。如果读者对这个工具不熟悉也没有关系，这里只是说明一下分析思路，这一章中还不需要对每个分析点具体了解。接到客户问题后，使用WinDbg 对服务器进程w3wp.exe dump 了一个文件，把dump 文件拿回本地分析，重启一下服务器，客户可继续使用系统。Dump 文件的过程是把应用运行中某一时刻的运行信息及状态写到文件中，查看一下线程池：0:025?!threadpool ?CPU?utilization:?99% ?Worker?Thread:?Total:?47?Running:?5?Idle:?42?MaxLimit:?800?MinLimit:?8 ?Work?Request?in?Queue:?0 ?-------------------------------------- ?Number?of?Timers:?46 ?-------------------------------------- ?Completion?Port?Thread:Total:?2?Free:?2?MaxFree:?16?CurrentLimit:?2?MaxLimit:?800?MinLimit:?8?说明：在本书中由于这样的分析展示比较多，关键数字我会以粗体进行标注，比如“99%”被标记为粗体显示。CPU 利用率比较高，dump 文件这一刻CPU 利用率是99%，说明很可能在这个dump 文件中能够找到线索。w3wp 通过内部多线程方式来同时处理多客户端请求，线程池的数量根据请求数自动分配，一般有几十个线程在工作。随便选择一个线程：0:025?kb ?ChildEBP?RetAddr?Args?to?Child ?1b24f974000003c000000000?ntdll!ZwWaitForSingleObject+0x15 ?1b24f9e0?76da1194?000003c0?ffffffffKERNELBASE!WaitForSingleObjectEx+0x98 ?1b24f9f8?6c3f1030?000003c0?ffffffffkernel32!WaitForSingleObjectExImplementation+0x75 ?1b24fa2c?6c3f1071?000003c0?ffffffffclr!CLREvent::CreateManualEvent+0xf6 ?1b24fa7c?6c3ed3e875393cd7clr!CLREvent::CreateManualEvent+0x137 ?1b24fabc?6c3ed409?ffffffff00000000?clr!CLREvent::WaitEx+0x126 ?1b24fad0?6c4391dd?ffffffff00000000?clr!CLREvent::Wait+0x19 ?1b24faf0?6c43a296?1afa00486c43a370?clr!SVR::t_join::join+0xef ?1b24fb10?6c43a08f1