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。