On Tue, Mar 11, 2014 at 9:13 PM, Julien T <[email protected]> wrote:
> Hello,
>
> another point, I need to discuss on the list is the cpu usage of ossec. On
> my test mac, it is often eating 50-90% of CPU.

I don't recall seeing this type of resource consumption on other
systems during most operations. This may just be one of the risks of
running a niche OS.

> After some tracking, it seems ossec-analysisd is responsible for it and w
> dtrace [1], it can be located like this
>
> # dtrace -n 'syscall:::entry { @num[execname] = count(); }'
> [...]
>   dbfseventsd                                                     509
>   ocspd                                                           670
>   ossec-syscheckd                                                1328
>   Google Drive                                                   1336
>   Google Chrome C                                                4961
>   Google Chrome H                                               40300
>   ossec-analysisd                                             1113498
> # dtrace -n 'syscall:::entry { @num[probefunc] = count(); }'
> [...]
>   psynch_cvwait                                                 17496
>   sigaltstack                                                   18142
>   sigprocmask                                                   18144
>   kevent                                                        25687
>   read_nocancel                                               2157214
> # readid.d ossec-analysisd 15s
> dtrace: 14240 dynamic variable drops with non-empty dirty list
> Sampling for 15s ... Please wait.
> [...]
> PROGRAM                PID     COUNT
> ossec-analysisd      47205     115635
> # readfile.d ossec-analysisd 60s
> [...]
> FILE NAME
> COUNT
> 'localtime
> ' '      7'
> 'syscheck
> ' ' 110891'
> # rwsnoop -n ossec-analysisd
> confirms an almost content call on those files of ${prefix}/var/ossec
> /etc/localtime
> /opt/local/var/ossec/queue/syscheck/syscheck
>
> not sure, why the first is needed multiple time. the latter seems to
> contains hash of files.
>
> In my config, syscheck is <frequency>72000</frequency> (default)
> is there an option to know how much time the full syscheck takes or to
> renice it?
> I was supposing after the first big initial scans, things to be more light,
> but it doesn't seem so.
>

The ossec.log should have entries for a scan starting and finishing.
internal_options.conf has some options for adjusting the speed of
syscheck (making it go slower can make it less resource intensive).

> Another anomaly is the process name: in Activity monitor, it's empy, while
> in 'ps'/cli, it's complete for ossec-analysisd, ossec-syscheck
> check: ps -p <pid> -o pid,command,comm,args,ucomm and all are set right
> The following explanations didn't seem relevant to me for a pure unix app or
> is there some stealth mode?
> http://stackoverflow.com/questions/4217947/setting-process-name-on-mac-os-x-at-runtime
> http://stackoverflow.com/questions/1046155/blank-process-name-for-osx-cocoa-application
>

Is it possible that this is a bug in the activity monitor? The process
names show up in standard *nix utilities just fine.

>
> Thanks.
> Cheers,
>
> Julien
>
>
> [1]
> http://blog.thilelli.net/post/2007/04/13/Tracking-Performance-Problem-with-DTrace
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to