Benchmarking the performance impact of auditd

[zhu xiuming]

So detailed explanation.
Thanks a lot.
Really appreciate it.


On Fri, Aug 30, 2013 at 11:34 AM, Steve Grubb <sgrubb at redhat.com> wrote:

> On Thursday, August 29, 2013 02:14:32 PM zhu xiuming wrote:
> > Thanks a lot.
> > May I ask for more information?
> >
> > I am a little confused by the code. What is the reason behind that?
>
> To measure the impact, you have to repeat the test over and over. So, what
> you
> want to do is create a test that does a syscall and loops on it. You test
> with
> audit disabled and then reboot with audit enabled and run the same test.
> You
> also have to shutdown as many dameons as possible because they alter the OS
> timing.
>
> > It seems that the test.c only access /usr/include directory.But "access"
> > does not trigger any rules in auditd.
>
> Sure it does. If you have a syscall rule on open, for example, the audit
> system does not know if the syscall is of interest. So it walks through the
> list of rules to see if any match the current syscall. If it does, then it
> starts walking through each field of that rule.
>
> So, if you want to do a thorough study, then you want to test both misses
> and
> hits to see how much time is spent in both cases and then compare that when
> the audit system is not enabled and no rules loaded to when the audit
> daemon
> is enabled and rules loaded. You might also compare to when the audit
> daemon
> is enabled but there are no rules loaded.
>
> > Or you mean the test.c only stress the cpu?
>
> Nope. Any syscall affects the audit system. But you want to do micro
> benchmarks
> to see the cumulative effect. Its easier to see a 5% performance hit on a
> microbenchmark that runs for 30 seconds than one that takes milliseconds to
> complete. You can also change the syscall to see if different syscalls have
> more impact than others. For example, the rename syscall probably gets hit
> hard because it has to create auxiliary records when there is a match. You
> might test networking as filesystem watches, too.
>
> -Steve
>
>
> > On Thu, Aug 29, 2013 at 1:24 PM, Steve Grubb <sgrubb at redhat.com> wrote:
> > > On Thursday, August 29, 2013 12:59:33 PM zhu xiuming wrote:
> > > > Has someone done some work related to the performance impact of
> enabling
> > > > auditd on syscalls watching?
> > >
> > > Yes, long ago.
> > > http://people.redhat.com/sgrubb/files/lspp-perf.tar.gz
> > >
> > > Short story is watches were undistinguishable from cache hit/misses and
> > > syscall auditing gets more impact as more rules get added and based on
> how
> > > complicated the rule is. CPU's have changed so much since I did the
> > > benchmarking that I won't even hazard a guess as to what the
> performance
> > > hit
> > > is on current hardware with current kernel.
> > >
> > > -Steve
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20130831/9d8ad9db/attachment.htm>