SharePoint 2007 filling hard drive with logs

I logged into our SharePoint server at work today and behold, the C:\ drive was full. It had a blazing 200Mb free, out of 150Gb I might ad. I almost fell of my chair, what the hell had happened.
I started by checking out the databases, I knew I had set recovery mode to simple a while back so they wouldn’t fill up the drive with Transaction Logs. So checking folder sizes I noticed that C:\Program Files\Common Files\Microsoft Shared\webserver extensions\12\logs was hogging over 140Gb.
What the h***?  Looking in the folder I found SHAREPOINT*.log files that were HUGE, some almost 7Gb. What’s going on here!
I tried to open a logfile, but as you might guess Notepad doesn’t open a text file that’s 7Gb. Who would want to open one anyway. What was I thinking. I guess I could sink a server by opening something that large(note to self: Trial of opening large files in controlled environment).

Google is your friend, your friend I tell you!

Fixing problems almost always involves checking online to se if someone else has run into the same problem. And behold, someone had. But not as many as I thought and the answers were a lot harder to find than I thought.
The problem seemed to have something to do with the SharePoint timer service( OWSTIMER.EXE ), so I stopped the service. Moved the logfiles to my desktop for further analysis if needed and restarted it. Seconds later I had a logfile about 50Mb in size. Stop the timer fast so I can open the logfile in Notepad.

OWSTIMER.EXE the bandit?

Reading the log showed a timed job hanging. Well to even get to the bottom of this I had to get the server logging less, the drives filled up to fast and I needed to keep the server up and running.

 

Process TID Area Category EventID Level

OWSTIMER.EXE (0x014C)

 0×0440 Windows SharePoint Services Timer 5uuf Monitorable

 

The next section is something you really shouldn’t do. Unless you are in a hurry and can’t afford to take the server offline.

Suppressing the logging!

Remember I said this is something you really should not do. If your server spits error logs faster than a chain gun shoots bullets you need to find the cause of it, not shut it up. Well I decided to get the logging down a notch before I get to the bottom of this, since as I said there really wasn’t a whole lot of documentation out there on this subject. And if like me you want to keep the server running during production hours and start the debugging after hours, since the server works fine for the users. The solution below,

  1. Start SharePoint Central Administration
  2. Go to Operations
  3. Select Logging and Reporting
  4. Select Diagnostic Logging
  5. Under event throttling choose All as category.
  6. Set least critical event to report to warning. I want to know anything that count’s as a warning or more serious than that. Unless I am debugging, and if I am I can always set the threshold lower again.
  7. Set the least critical event to report to trace file to Unexpected. OWSTIMER.EXE error is giving out an Monitorable so setting it any lower and you’ll still fill up your drives.
  8. Under trace log set number of logfile to something more reasonable than the default ( I had 96 files times 7Gb is quite something ), I set it at 10. And set the number of minutes to use a logfile to 60. If nothing really weird is happening 60 minutes should be ok.

Getting to the bottom of it

Sorry to say I couldn’t find the cause of this horrible logging. But I’m not going to quit searching. This post was just to save fellow administrators some time, without SharePoint filling your drive.

If you are reading this and already solved this problem, please share your fix. There might be many out there battling the same issue. And if when I find a solution to this I will be posting about it.

No related posts.

Comments

    Joe P posted the comment on May 3rd, 2010

  1. Thanks man for posting this.

    It saved me some time.

    -Joe P

    2. Mats Hellman posted the comment on May 4th, 2010

  2. No problem. It’s been one of the more visited articles on the site :)

    3. MichelleS posted the comment on August 24th, 2010

  3. Someone suggested the culprit is the Sharepoint Configuration Cache: http://blog.sdbonline.com/blog/post/SharePoint-log-files-grow-extremely-large.aspx