Thank you very much for all the input. I'll try changing these parameters. Also, I will install on another Windows Server 2003 client and look for differences in behavior.
Terry Daniel Cid wrote: > > Hi Gentuxx (and all), > > Thanks for the information. Disk stability and quality can really > after syscheck > usage (since it needs to read all the files).I have been looking at it > and I think I > found the problem. > Basically, by default, syscheck is executed every two hours. However, > the time > it takes to finish, can be from 20 minutes to 30 minutes (depending on > the system). > It takes that long because at every 15 files we sleep "2" seconds to do > not kill > the system completely. This values can be changed to sleep more often or > longer... So, if it takes 30 minutes to finish the scan, syscheck will > be running > almost all the time (1/4). In addition to that, to answer Rick question, > ossec > generates the checksum database every time it starts. It does that because > it can't trust the system and needs to forward all the data to the server. > > > To make ossec use less cpu, try the following: > > -Change syscheck frequency from 7200 (2 hours) to 86200 or other higher > value > at ossec.conf (make sure to restart ossec). > > -Edit internal_options.conf and edit the values of (you can increase the > values > to sleep 3 or 4 seconds at every 10 or 5 files): > > # Syscheck checking/usage speed. To avoid large cpu/memory > # usage, you can specify how much to sleep after generating > # the checksum of X files. The default is to sleep 2 seconds > # after reading 15 files. > syscheck.sleep=2 > syscheck.sleep_after=15 > > > Next version will have this issue solved (basically the defaults will > be longer)... > > Hope it helps.. > > -- > Daniel B. Cid > dcid ( at ) ossec.net > > On 10/6/06, gentuxx <[EMAIL PROTECTED]> wrote: >> > Terry Morreale wrote: >> Thank you for the response. > >> While it is not always over 60%, it is pretty much always over 40%. I >> have been watching it for about a day, and it bounces around between > 40% >> and 75%. > >> I am running the agent on Windows Server 2003. Also, I did change the >> syscheck interval to every 12 hours instead of every two hours - but it >> doesn't seem to have helped. > > > How sure are you of the stability of the disk(s) in this system? Also, > how are you measuring the processor time the process is getting? > >> Daniel Cid wrote: >>> Hi Terry, > >>> Is the ossec cpu usage that high all the time? It should only go up >>> like that when you start ossec (since it will scan the file system >>> generating checksum of the files). > > Daniel (et al.), I'm actually seeing results that are all over the > spectrum. I've got one box where the process usage is virtually nil, > another that is averaging about 15%, and another that seems to be > averaging about 60%. All three are WinXPSP2. Instead of trying to > watch this in Task Manager, I've set up a performance counter for this > process specifically. Right now, I'm just watching "% Processor Time", > but it might be interesting to add other counters as well (IO > Read/Writes, etc.) > > [....SNIP....] >>> On 10/5/06, Terry Morreale <[EMAIL PROTECTED]> wrote: >>>> Folks, >>>> I have installed the Windows agent but am seeing CPU utilization > by the >>>> ossec process at about 60%. Has anyone found a way to keep > utilization >>>> lower, maybe around 10%? >>>> > > [...SNIP...] > > Here's the interesting part, and part of why I ask about the stability > of your disk(s), Terry. The system that is virtually nil, has 3x 80GB > "known good" drives, with about 20K files (in addition to system and > program files). The system that is averaging about 15% has 1x 30GB > "known bad (but still functional)" drive, and really doesn't have much > in the way of "stored data". And the system that is averaging 60% usage > has 2x 40GB in RAID0, and 1x 120 GB "known good" drive, and has around > 3.5M files (including OS and program files). I have had my suspicions > (because of other indicators) that at least one of the 40GB drives is > going bad. So, I'm guessing that this is related to the amount of disk > IO that your system is doing, and how well it is able to do that IO. > > Incidentally, in the time it took to write this email, the one that was > at 15% is now down around nil, and the other that was at 60% is now > around 15%. So, I'm guessing that they were all running their scans > when I first started watching. (I still have mine set for every 2 > hours.) > > So, a lot of words for not really a resolution, but interesting > nonetheless. > >> -- ------------------------------------------------------------------------------- Terry Morreale Applied Trust Engineering - www.atrust.com - 303.245.4507 Security - Performance - Availability - Incident Management
