What are the implications of exceeding 4 GB in a Windows Event Log

windows-event-logwindows-server-2008-r2windows-server-2012windows-server-2012-r2

I found this Microsoft KB that covers recommended Event Log setting maximums for operating systems up to Windows 2008/Vista, which recommends a maximum of 4GB, and have seen some other vague references that an Event Log larger than 4 GB is not recommended in at least 2008 R2, but I'm wondering what actually happens if an event log exceeds this size?

I've exceeded this on a test server (2012 R2) and haven't noticed anything like high memory usage etc. We don't care about OSes before 2008 R2, but want a large log because we are collecting events from many machines via Windows Event Forwarding and want to have all the events in one place.

Best Answer

Other than the awful performance and ridiculous wait times when you have to load a 4 GB log and the hell it will be if you ever have to search through such a monstrous thing, not much. I think the largest one I've seen in my environments was 10 GB, and although I gave up waiting on it to load, it didn't seem to harm anything.

The 4GB caution for Server 2008 is due to that 32-bit limit that's often encountered at 4 GB. On a 64 bit system, you should be fine to let it grow to up to 16 TB (or 64, depending), though I don't know that anyone's gotten anywhere close to testing that limit.

Of course, if you haven't already, you'll discover that very large log files are simply impractical to use - the last time I tried to load a simple 100 GB (text) log file, it couldn't even be opened without crashing the application opening it, and I suspect you'll hit that issue well before 100 GB.

The far better approach is to limit the file size to something reasonable, and use a script to clear it out from time to time. I use the below in my environment, combined with a 1 GB size limit on our security log. Some (well, most) of our servers generate over 3 GB of security events per day, and we don't want to waste all that space on huge log files I'll quit before combing through, so my script copies the log contents to another folder and then clears the event log to be written to again. And since the folder I copy them to is backed up, we can always go back to the logs in the horrible event that we need to.

#Adapted from: http://blogs.technet.com/b/heyscriptingguy/archive/2009/04/08/how-can-i-check-the-size-of-my-event-log-and-then-backup-and-archive-it-if-it-is-more-than-half-full.aspx

Param($logName = "security",$backupFolder = "C:\backupLogs")

Function Get-EventLog([string]$logName)
{
 $log = Get-WmiObject -Class Win32_NTEventLogFile -filter "LogFileName = '$logName'"
 If($log.FileSize / $log.MaxFileSize -ge .9)
  {
   "Log is at least 90% full. Backing up now."
   Backup-EventLog($log)
  } #end if
 Else 
 { 
   "Not backed up: $logName is only " + ($log.FileSize / $log.MaxFileSize).tostring("N2") +  " percent full" 
 } #end else
} #end Get-EventLog

Function Backup-EventLog($log)
{
 $folder = Join-Path -Path $BackUpFolder -ChildPath (Get-Date).ToString("MMddyy_hhmm")
 If(-not(Test-Path $folder)) 
   { 
     New-Item -path $folder -itemtype Directory -force | out-Null
   }
  $rtn = $log.BackupEventLog("$folder\$logName.evt").ReturnValue
  If($rtn -eq 0)
    {
     $log.ClearEventLog() | out-null
    } #end if
 ELSE 
   {
    "$logName could not be cleared. Backup ended with $($rtn)" 
  }
} #end Backup-EventLog

# *** ENTRY POINT ***
Get-EventLog -logname $logname
Related Topic