認識w3wp.exe進程,從根本上解決占用資源較大問題

發布時間：2019-12-14 16:19

來源：互聯網

當前欄目：web技術類

在windows server 2003中對于每一個web應用，iis 6.0都用一個獨立的w3wp.exe的實例來運行它。w3wp.exe也稱為工作進程(每一個主機頭都會有一個)

直接在任務管理器中結束進程是不起作用的，結束后不久它會執行啟動，要想結束它可以在iis中找到相應的應用程序池停止相應的應用程序池工作。

這些都不是解決辦法，它的根本問題是你的那個網站程序有問題，在找到問題以前可以先打開iis找到應用程序池先用右鍵屬性中設置“性能”把其中的cpu設成大于60%關閉應用程序池，把關閉時間和開啟時間設短一些比如10秒，這樣當您的網站程序大量占用系統資源時iis自動快速回收進程并且快速啟動進程，您的網站暫時還可以將就著工作。

要解決根本問題還要從程序查起，您可以在iis中的應用程序池中右鍵創建多個應用程序池，然后在每個主機頭中的文件家選項的底部將應用程序池對應道剛才建好的應用程序池，然后一個一個關閉在任務管理器中看看是哪個程序占用的資源較大。

下面是一些網友的相關貼子也許對大家有幫助

朋友的web服務器一直運行正常，但這幾天cpu占用率一直將近100%，遂去看個究竟。

服務器采用windows 2003, 網站使用asp+access數據庫, 查看進程列表發現w3wp.exe 占用了70%以上的cpu，

查看web日志，站點訪問量不大，查看tcp連接也不多。用net stop w3svc停掉web服務，cpu占用立即正常，net start w3svc啟動web后不久現象又出來了。停止所有虛擬站點，新建一個虛擬站點發現并沒有問題，懷疑是站點本身的代碼問題。

檢查首頁代碼，大致是如下結構：

粗看一下并沒有問題，但就是這段代碼造成了w3wp.exe占用大量cpu，難道是死循環？似乎沒有理由。在循環體內加入計數，發現確實是死循環，說明rs.eof一直為false，加入如下代碼：

if rs.eof = true then response.write "eof is true"

if rs.eof = false then response.write "eof is false"

發現輸出竟然是eof is true eof is false, 說明無法判斷rs.eof的值，為何如此百思不得其解。檢查數據庫，發現庫中并沒有mytable表, 如果該表不存在，rs.open "select * from mytable", conn 就會出錯，為何沒有出錯，很有可能捕獲的異常被忽略了。

檢查包含文件conn.asp, 發現了異常處理代碼：

on error resume next

原來問題在此。

on error resume next忽略了查詢表時的失敗以及后續的錯誤，造成進入死循環。

那為何網站本來運行正常，現在卻找不到mytable表了呢？仔細檢查網站才發現“有‘客'自遠方來”，上傳了后門工具、刪除了多張數據表，害我忙活了一天。

更多的內容大家還可以到：http://www.microsoft.com/china/technet/security/guidance/secmod93.mspx

查找更詳細的安全設置

windows2003? iis6.0假死問題解決

這幾天服務器總是運行緩慢，遠程登錄后發現一個w3wp.exe的進程占用了100%? cpu。

問題的原因最終找到兩個：

1.采用的jet? 數據庫連接方式存在問題：http://support.microsoft.com/?id=838306

補丁下載：

chs:windowsserver2003-kb838306-x86-chs.exe

enu:windowsserver2003-kb838306-x86-enu.exe

2.將access數據庫擴展名改為asp

下面是我的差錯過程和解決方案：

搜索一下發現類似問題還真不少，那個w3wp的進程是iis6.0的應用程序池，網上的說法有兩種，一是因為asp或者asp.net代碼中含有死循環引起的。但是服務器上這么多網站，誰知道那個網站出了問題。二是由于上面的jet連接數據庫方式的bug引起的，下載838306的補丁，或者升級到sp1可以解決這個問題，但是打了這個補丁后，有些網站的問題依然存在。

總結

以上是生活随笔為你收集整理的mysql-nt.exe w3wp.exe cpu 100%_认识w3wp.exe进程,从根本上解决占用资源较大问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。