分析案例：应用服务器W3WP进程CPU持续超过百分之九十（Oracle客户端Bug）

问题描述：

项目反馈应用负载的其中一台服务器业务操作的响应非常慢，登录该服务器发现W3WP进程CPU持续超过90%，哪怕在业务低峰期也是如此？远程查看后发现该应用服务器承载的请求确实很低，why？？？

原因分析：

抓取w3wp进程的dump发现，正在运行的线程都没有我们系统的堆栈代码。并且长时间运行的工作线程的栈顶基本都是Oracle.DataAccess.Client.OracleTuningAgent.DoScan() ----》Oracle.DataAccess.Client.OracleTuningAgent.TuningFunction()相关的调用。

根据Oracle.DataAccess.Client.OracleTuningAgent.TuningFunction()等代码提示查阅资料，发现貌似和Oracle服务器及客户端版本有关系，经对比该应用和其他应用服务器，发现有问题的应用服务器上的Oracle客户端版本确实比较低（11.2.0.1），其他响应正常应用服务器的Oracle客户端版本为11.2.0.3。联系现场升级Oracle客户端版本后问题消失。

参考：http://stackoverflow.com/questions/2782169/oracle-data-provider-pegs-iis-worker-process-when-web-site-is-stopped

This has been fixed in 11.2.0.2 and in Patch 9966926 ORACLE 11G 11.2.0.1 PATCH 5 BUG FOR WINDOWS (64-BIT AMD64 AND INTEL EM64T).

Or WORKAROUND: is to disable self tuning by adding "Self Tuning=false" to the connection string.

dump日志如下：

0:000> !runaway
 User Mode Time
  Thread       Time

60:13fdc 2 days 19:54:05.922

62:3314 2 days 19:25:29.443

64:e0c 2 days 16:46:44.319

  75:ef2c       0 days 2:06:17.155
  67:198ac      0 days 1:54:59.175
  76:1afe4      0 days 1:41:53.460
  20:19f0c      0 days 0:04:41.145

OS Thread Id: 0x13fdc (60)
        Child SP               IP Call Site
0000000030c9dcc8 00000000779cd3fa [InlinedCallFrame: 0000000030c9dcc8] System.Exception.GetMessageFromNativeResources(ExceptionMessageKind, System.Runtime.CompilerServices.StringHandleOnStack)
0000000030c9dcc8 000007fef86e5aca [InlinedCallFrame: 0000000030c9dcc8] System.Exception.GetMessageFromNativeResources(ExceptionMessageKind, System.Runtime.CompilerServices.StringHandleOnStack)
0000000030c9dca0 000007fef86e5aca *** WARNING: Unable to verify checksum for mscorlib.ni.dll
System.Threading.ThreadAbortException..ctor()
0000000030c9df40 000007fef974a7f3 [GCFrame: 0000000030c9df40]
0000000030c9dfc8 000007fef974a7f3 [GCFrame: 0000000030c9dfc8]
0000000030c9e130 000007fef974a7f3 [GCFrame: 0000000030c9e130]
0000000030c9e5c8 000007fef974a7f3 [HelperMethodFrame: 0000000030c9e5c8]
0000000030c9e6f0 000007fe9a1774fa *** ERROR: Module load completed but symbols could not be loaded for Oracle.DataAccess.dll
Oracle.DataAccess.Client.OracleTuningAgent.DoScan()
0000000030c9e740 000007fe9a1688e5 Oracle.DataAccess.Client.OracleTuningAgent.TuningFunction()
0000000030c9e7c0 000007fef86339a5 System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
0000000030c9e920 000007fef8633719 System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
0000000030c9e950 000007fef86336f7 System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
0000000030c9e9a0 000007fef864adc1 System.Threading.ThreadHelper.ThreadStart()
0000000030c9ecb8 000007fef974a7f3 [GCFrame: 0000000030c9ecb8]
0000000030c9f008 000007fef974a7f3 [DebuggerU2MCatchHandlerFrame: 0000000030c9f008]
0000000030c9f198 000007fef974a7f3 [ContextTransitionFrame: 0000000030c9f198]
0000000030c9f3b8 000007fef974a7f3 [DebuggerU2MCatchHandlerFrame: 0000000030c9f3b8]
OS Thread Id: 0x20bd4 (61)
        Child SP               IP Call Site
00000000031bdc58 00000000779cd96a [HelperMethodFrame: 00000000031bdc58] System.AppDomain.nUnload(Int32)
00000000031bdd50 000007fef8e3e892 System.AppDomain.Unload(System.AppDomain)
00000000031bddb0 000007fef4b0c4a2 *** WARNING: Unable to verify checksum for System.Web.ni.dll
System.Web.HttpRuntime.ReleaseResourcesAndUnloadAppDomain(System.Object)
00000000031bde30 000007fef86339a5 System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
00000000031bdf90 000007fef8633719 System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
00000000031bdfc0 000007fef866216f System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
00000000031be010 000007fef866136a System.Threading.ThreadPoolWorkQueue.Dispatch()
00000000031be578 000007fef974a7f3 [DebuggerU2MCatchHandlerFrame: 00000000031be578]
00000000031be708 000007fef974a7f3 [ContextTransitionFrame: 00000000031be708]
00000000031be928 000007fef974a7f3 [DebuggerU2MCatchHandlerFrame: 00000000031be928]
OS Thread Id: 0x3314 (62)
        Child SP               IP Call Site
0000000003bee5b8 00000000779cd3fa [HelperMethodFrame: 0000000003bee5b8]
0000000003bee6e0 000007fe9a1774fa Oracle.DataAccess.Client.OracleTuningAgent.DoScan()
0000000003bee730 000007fe9a1688e5 Oracle.DataAccess.Client.OracleTuningAgent.TuningFunction()
0000000003bee7b0 000007fef86339a5 System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
0000000003bee910 000007fef8633719 System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
0000000003bee940 000007fef86336f7 System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
0000000003bee990 000007fef864adc1 System.Threading.ThreadHelper.ThreadStart()
0000000003beeca8 000007fef974a7f3 [GCFrame: 0000000003beeca8]
0000000003beeff8 000007fef974a7f3 [DebuggerU2MCatchHandlerFrame: 0000000003beeff8]
0000000003bef188 000007fef974a7f3 [ContextTransitionFrame: 0000000003bef188]
0000000003bef3a8 000007fef974a7f3 [DebuggerU2MCatchHandlerFrame: 0000000003bef3a8]
OS Thread Id: 0xa130 (63)
        Child SP               IP Call Site
0000000003ecdc48 00000000779cd96a [HelperMethodFrame: 0000000003ecdc48] System.AppDomain.nUnload(Int32)
0000000003ecdd40 000007fef8e3e892 System.AppDomain.Unload(System.AppDomain)
0000000003ecdda0 000007fef4b0c4a2 System.Web.HttpRuntime.ReleaseResourcesAndUnloadAppDomain(System.Object)
0000000003ecde20 000007fef86339a5 System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
0000000003ecdf80 000007fef8633719 System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
0000000003ecdfb0 000007fef866216f System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
0000000003ece000 000007fef866136a System.Threading.ThreadPoolWorkQueue.Dispatch()
0000000003ece568 000007fef974a7f3 [DebuggerU2MCatchHandlerFrame: 0000000003ece568]
0000000003ece6f8 000007fef974a7f3 [ContextTransitionFrame: 0000000003ece6f8]
0000000003ece918 000007fef974a7f3 [DebuggerU2MCatchHandlerFrame: 0000000003ece918]
OS Thread Id: 0xe0c (64)
        Child SP               IP Call Site
000000000528e918 00000000779cd3fa [HelperMethodFrame: 000000000528e918]
000000000528ea40 000007fe9a1774fa Oracle.DataAccess.Client.OracleTuningAgent.DoScan()
000000000528ea90 000007fe9a1688e5 Oracle.DataAccess.Client.OracleTuningAgent.TuningFunction()
000000000528eb10 000007fef86339a5 System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
000000000528ec70 000007fef8633719 System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
000000000528eca0 000007fef86336f7 System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
000000000528ecf0 000007fef864adc1 System.Threading.ThreadHelper.ThreadStart()
000000000528f008 000007fef974a7f3 [GCFrame: 000000000528f008]
000000000528f358 000007fef974a7f3 [DebuggerU2MCatchHandlerFrame: 000000000528f358]
000000000528f4e8 000007fef974a7f3 [ContextTransitionFrame: 000000000528f4e8]
000000000528f708 000007fef974a7f3 [DebuggerU2MCatchHandlerFrame: 000000000528f708]

其他注意事项：

经查触发这个bug的代码时BulkCopy，使用Oracle的BulkCopy还是要慎用。

参考信息：

http://www.cnblogs.com/zhaoguan_wang/p/5505751.html

http://www.cnblogs.com/xling/p/4347165.html

时间： 2024-08-19 08:46:58

分析案例：应用服务器W3WP进程CPU持续超过百分之九十（Oracle客户端Bug）的相关文章

python监听windows上w3wp进程，如果cpu>=95%则自动kill掉

因为最近服务器前端虽然加了负载均衡,但是后端windows主机偶尔还有因为服务进程cpu到99这种情况导致服务不可用,虽然这个不用第一时间处理,但是也需要手工登录进行进程的kill,windows下可以通过dos脚本写个.bat脚本实现这个功能,并通过配置调用这个.bat脚本,但是我试过几次感觉不太适合我 所以通过python写一个脚本并用py2exe转换成.exe程序放在几台windows上,因为不可能每台server都手工部署下python环境. 代码如下: import psutil im

查看w3wp进程占用的内存及.NET内存泄露,死锁分析

一 基础知识 在分析之前,先上一张图: 从上面可以看到,这个w3wp进程占用了376M内存,启动了54个线程. 在使用windbg查看之前,看到的进程含有 *32 字样,意思是在64位机器上已32位方式运行w3wp进程.这个可以通过查看IIS Application Pool 的高级选项进行设置: 好了,接下打开Windbg看看这个w3wp进程占用了376M内存,启动的54个线程. 1. 加载 WinDbg SOS 扩展命令 .load C:\Windows\Microsoft.NET\Fram

查看w3wp进程占用的内存及.NET内存泄露,死锁分析--转载

一 基础知识 在分析之前,先上一张图: 从上面可以看到,这个w3wp进程占用了376M内存,启动了54个线程. 在使用windbg查看之前,看到的进程含有 *32 字样,意思是在64位机器上已32位方式运行w3wp进程.这个可以通过查看IIS Application Pool 的高级选项进行设置: 好了,接下打开Windbg看看这个w3wp进程占用了376M内存,启动的54个线程. 1. 加载 WinDbg SOS 扩展命令 .load C:\Windows\Microsoft.NET\Fram

云计算之路-阿里云上：消灭“黑色n秒”第二招——给w3wp进程指定CPU核

虽然昨天的第一招失败了,但是从失败中我们学到了与多核CPU相关的Processor Affinity(处理器关联)的知识. 既然我们可以让.NET程序的不同线程运行于指定的CPU核,那是不是也可以让IIS应用程序池的进程w3wp运行于指定的CPU核? 虽然看起来"黑色n秒"似乎与w3wp运行于哪些CPU核没有什么关系,但是我们既然把怀疑对象锁定在CPU,那么任何与CPU相关的线索都不能放过.即使失败,也会满载而归,因为如果没有"黑色n秒"这个问题的驱动,我们根本不会

Linux下分析某个进程CPU占用率高的原因

  Linux下分析某个进程CPU占用率高的原因 通过top命令找出消耗资源高的线程id,利用strace命令查看该线程所有系统调用  1.top 查到占用cpu高的进程pid 2.查看该pid的线程:top -H -p 9532 3.查看这个线程所有系统调用:strace -p 10017 不停循环输出Connection timed out,让开发查看问题 原文地址:https://www.cnblogs.com/chenjw-note/p/8370679.html

Linux下java进程CPU占用率高分析方法

Linux下java进程CPU占用率高分析方法 在工作当中,肯定会遇到由代码所导致的高CPU耗用以及内存溢出的情况.这种情况发生时,我们怎么去找出原因并解决. 一般解决方法是通过top命令找出消耗资源高的线程id,利用strace命令查看该线程所有系统调用 1. 通过top命令找到可疑进程PID top - 09:37:18 up 70 days, 16:29, 2 users, load average: 1.13, 1.04, 0.97 Tasks: 105 total, 1 running

Linux下java进程CPU占用率高-分析方法

今天登陆同事的一台gateway 开始以为hive环境登陆不了了,仔细一看看了下是因为机器很卡,我每次等几秒没登陆就ctrl+c了,看了下是有个java进程cpu:340.4%  mem:14.6% 一般解决方法是通过top命令找出消耗资源高的线程id,利用strace命令查看该线程所有系统调用 1. 通过top命令找到可疑进程PID top 一下 可以看出java进程CPU利用率一直保持100%,稳居不下,找到PID 24138 2. 找出消耗资源最高的线程 top -H -p  29580 

w3wp.exe CPU过百问题

w3wp.exe CPU过百问题 最近发布在windows  server2012  IIS8.0上的一个WebAPI项目,才几十个人在线,CPU就会出现过百情况,并且CPU一旦过百应用程序池就自动暂停掉,看到这个问题我感觉应该是程序哪个地方出了问题, 8盒16G 应该配置还是可以的.打算使用windbg找到这个问题. 为了快速定位问题我就直接在生产环境安装了windbg,为了采集dump文件,我选择Procdump.Procdump无需安装,下载下来直接放到一个目录下即可.以下是解决问题的过程

记一次w3wp占用CPU过高的解决过程（Dictionary和线程安全）

项目上线以来一直存在一个比较揪心的问题,和一个没有信心处理的BUG,那就是在应用程序启动时有可能会导致cpu跑满99%或持续在一个值如50%左右,这样一来对服务器的压力是非常大的,经常出现服务器无法远程的状态,唯有通过PowerShell杀掉对应的w3wp进程才可以解决这个问题. 为什么没有信心处理这个问题 原因非常简单,这个问题是间歇性的,不容易重现的,只会在项目启动时有一定的可能性会发生CPU跑满的问题. 所有可以重现的BUG的处理都不会太难,而类似这种无法重现的BUG是最让人头疼的,因为它