剛纔登錄上我的Hyper-v實驗平臺 IBMx3650， 吃驚的看到一臺虛機的狀態爲“存儲不夠”，轉眼看我的C盤已由巨大的600G變成7G，多麼悲涼的一個畫面，我真該截張圖下來。
本以爲可能是我做Hyper-v的快照搞的。。PS ：快照從未成功過，這會本應該調查快照來着
於是各種右鍵屬性，終於找到了罪魁禍首。SharePoint的日誌！<C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\LOGS>這個畸形的種子在3天內漲了500G有餘。
裏面的日誌文件大多以<主機名+時期+時間>.log 命名,小個的0K，大個的50多G！打開了個20M的 內容爲如下的循環：
<11/25/2010 03:10:34.91 OWSTIMER.EXE (0x0928) 0x093C Windows SharePoint Services Timer 5uuf Monitorable 由於服務“{0FD723E5-2750-45F5-8E76-E346E7435650}”上的 ID 爲“{1DC33A20-51B9-4180-85F9-B7B03AD4AB12}”的計時器作業“配置刷新”的上一個實例仍在運行，所以將跳過當前實例。請考慮增加作業的間隔時間。>
我無法證實大個的也是同樣的內容，十多g的txt，用notepad打開我要等到月亮上天。。
幸好早已有同仁受過此難：
http://www.cnblogs.com/bear-study-hard/archive/2009/01/12/1374061.html
logs-filling-up-entire-di.aspx
clear-the-sharepoint-configuration-cache-for-timer-job-and-psconfig-errors.aspx
誠惶誠恐中我立即採取了清理、限制日誌的操作，沒有仔細檢查計時器作業狀態。。
這些也只是清理了日誌以及限制日誌生成速度，而計時器作業究竟發生了什麼以及哪個計時器、哪個服務目前無從而知。。
不知道會不會跟我前天改了服務器時間有關。。