OWSTIMER.EXE causes a high CPU usage

from:

http://blog.darkthread.net/blogs/darkthreadtw/archive/2007/03/08/owstimer-exe-causes-a-high-cpu-usage.aspx

 

 

自從安裝WSS3之後,不定時會發現OWSTIMER.EXE Process的CPU使用量忽然衝高,同時HD聲不斷閃爍的狀況。前後不定時發生過好幾次,今天終於忍不住用Process Monitor追了一下,發現有個寫入C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS\MahineName-yyyyMMdd-HHmm.log的動作,再一看Log,不得了! Log居然長大到近200MB的大小,檢視的結果,裡面有一大堆如下的Log,一秒鐘就產生數十筆。

03/08/2007 14:23:54.15 OWSTIMER.EXE (0x07A8) 0x07B4 Windows SharePoint Services Timer 5uuf Monitorable The previous instance of the timer job '設定重新整理', id '{7395AF13-764D-4745-8911-3F37C333DB18}' for service '{FC0283B2-109C-4FA5-B91E-5B7A01BE8426}' is still running, so the current instance will be skipped. Consider increasing the interval between jobs.

這可以解釋為什麼CPU衝高,HD聲大作,而且應該CPU愈快,情況愈嚴重吧! (我可憐的E6400)

Google了一下,有不少同病相憐的人提問,但沒有答案。換了一下關鍵字"owstimer config refresh",找到這篇說明。由說明中看來,這類訊息屬於Information等級,基於某種狀況反覆發生(非致命性),大量寫入Log反而形成問題。依文章中的說明到"Sharepoint 3.0 管理中心/作業/診斷記錄/事件節流"下調了"計時器"的"回報至追蹤記錄的最低緊急事件"為"未預期"(Unexpected),雖成效仍有待觀察,但我想應該已經打到要害了。

最後順便示範一下Google解答的小技巧,一開始我用"OWSTIMER.EXE owstimer "The previous instance of the timer job"去找,只找到兩筆沒有答案的Post,但第二筆結果中出現了"the timer job 'Config Refresh'"的字樣,我確定了"設定重新整理"的英文原來是Config Refresh,再用"owstimer config refesh"去找,就發現了我要的答案。當第一波查詢沒有答案時,可以利用相關的結果修正你的關鍵字,這個技巧非常有用,是我在這行混飯吃的重要密技(驚! 我怎麼說了出來?),也證明了裝英文版,查問題時可以少個七八個Click。

posted @ 2008-09-25 22:10  laputa'sky  阅读(373)  评论(0编辑  收藏  举报