Try configuring external syslog server...that way ur disk is free of I/o...<div>Are you opening/closing same file again and again or different files?</div><div>If external syslog server is not possible, try to open files from a disk that is not used by syslog...<span></span><br><br>On Thursday, January 29, 2015, Richard Guy Briggs <<a href="mailto:rgb@redhat.com">rgb@redhat.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 15/01/29, Viswanath, Logeswari P (MCOU OSTL) wrote:<br>
> Please read my question as “Is there any option to configure kaudit<br>
> not to log audit records to syslog? when auditd not running.”<br>
<br>
Yeah, remove audit=1 from the kernel command line, or set audit=0 in its<br>
place.  This will stop all but AVCs and if auditd has ever run since<br>
boot.  If audit=0 is on the kernel boot line, it will be impossible to<br>
run auditd.<br>
<br>
There is a feature request that is likely coming soon that could be<br>
useful:<br>
<br>
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1160046" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=1160046</a><br>
"If no audit daemon is running, but an audit multicast subscriber is<br>
around, then the kernel shouldn't forward audit data to kmsg"<br>
<br>
> From: Viswanath, Logeswari P (MCOU OSTL)<br>
> Sent: Thursday, January 29, 2015 11:49 AM<br>
> To: 'Satish Chandra Kilaru'; Steve Grubb<br>
> Cc: <a href="javascript:;" onclick="_e(event, 'cvml', 'linux-audit@redhat.com')">linux-audit@redhat.com</a><br>
> Subject: RE: Linux audit performance impact<br>
><br>
> Is there any option to configure kaudit not to log audit records to syslog when auditd is running?<br>
> This way we can assess the impact of enabling audit without involving disk I/o overhead.<br>
><br>
> From: Satish Chandra Kilaru [mailto:<a href="javascript:;" onclick="_e(event, 'cvml', 'iam.kilaru@gmail.com')">iam.kilaru@gmail.com</a>]<br>
> Sent: Thursday, January 29, 2015 9:12 AM<br>
> To: Steve Grubb<br>
> Cc: <a href="javascript:;" onclick="_e(event, 'cvml', 'linux-audit@redhat.com')">linux-audit@redhat.com</a><mailto:<a href="javascript:;" onclick="_e(event, 'cvml', 'linux-audit@redhat.com')">linux-audit@redhat.com</a>>; Viswanath, Logeswari P (MCOU OSTL)<br>
> Subject: Re: Linux audit performance impact<br>
><br>
> I agree with you... but writing to disk can trigger further events leading spiralling of events...<br>
> I brought down my server few times with stupid rules...<br>
><br>
> On Wed, Jan 28, 2015 at 10:39 PM, Steve Grubb <<a href="javascript:;" onclick="_e(event, 'cvml', 'sgrubb@redhat.com')">sgrubb@redhat.com</a><mailto:<a href="javascript:;" onclick="_e(event, 'cvml', 'sgrubb@redhat.com')">sgrubb@redhat.com</a>>> wrote:<br>
> On Wednesday, January 28, 2015 10:18:47 AM Satish Chandra Kilaru wrote:<br>
> > Write your own program to receive audit events directly without using<br>
> > auditd...<br>
> > That should be faster ....<br>
> > Auditd will log the events to disk causing more I/o than u need...<br>
><br>
> But even that is configurable in many ways. You can decide if you want logging<br>
> to disk or not and what kind of assurance that it made it to disk and the<br>
> priority of that audit daemon. Then you also have all the normal tuning knobs<br>
> for disk throughput that you would use for any disk performance critical<br>
> system.<br>
><br>
> -Steve<br>
><br>
> > On Wednesday, January 28, 2015, Viswanath, Logeswari P (MCOU OSTL) <<br>
> ><br>
> > <a href="javascript:;" onclick="_e(event, 'cvml', 'logeswari.pv@hp.com')">logeswari.pv@hp.com</a><mailto:<a href="javascript:;" onclick="_e(event, 'cvml', 'logeswari.pv@hp.com')">logeswari.pv@hp.com</a>>> wrote:<br>
> > >  Hi Steve,<br>
> > ><br>
> > > I am Logeswari working for HP.<br>
> > ><br>
> > ><br>
> > ><br>
> > > We want to know audit performance impact on RHEL and Suse linux to help us<br>
> > > evaluate linux audit as data source for our host based IDS.<br>
> > ><br>
> > > When we ran our own performance test with a test audispd plugin, we found<br>
> > > if a system can perform 200000 open/close system calls per second without<br>
> > > auditing, system can perform only 3000 open/close system calls auditing is<br>
> > > enabled for open/close system call which is a HUGE impact on the system<br>
> > > performance. It would be great if anyone can help us answering the<br>
> > > following questions.<br>
> > ><br>
> > ><br>
> > ><br>
> > > 1)      Is this performance impact expected? If yes, what is the reason<br>
> > > behind it and can we fix it?<br>
> > ><br>
> > > 2)      Have anyone done any benchmarking for performance impact? If yes,<br>
> > > can you please share the numbers and also the steps/programs used the run<br>
> > > the same.<br>
> > ><br>
> > > 3)      Help us validating the performance test we have done in our test<br>
> > > setup using the steps mentioned along with the results attached.<br>
> > ><br>
> > ><br>
> > ><br>
> > > Attached test program (loader.c) to invoke open and close system calls.<br>
> > ><br>
> > > Attached idskerndsp is the audispd plugin program.<br>
> > ><br>
> > > We used time command to determine how much time the system took to<br>
> > > complete 50000 open/close system calls without (results attached<br>
> > > Without-auditing) and with auditing enabled on the system<br>
> > > (With-auditing-NOLOG-audispd-plugin and With-auditing-RAW)<br>
> > ><br>
> > ><br>
> > ><br>
> > > System details:<br>
> > ><br>
> > ><br>
> > ><br>
> > > 1 CPU machine<br>
> > ><br>
> > ><br>
> > ><br>
> > > *OS Version*<br>
> > ><br>
> > > RHEL 6.5<br>
> > ><br>
> > ><br>
> > ><br>
> > > *Kernel Version*<br>
> > ><br>
> > > uname –r<br>
> > ><br>
> > > 2.6.32-431.el6.x86_64<br>
> > ><br>
> > ><br>
> > ><br>
> > > Note: auditd was occupying 35% of CPU and was sleeping for most of the<br>
> > > time whereas kauditd was occupying 20% of the CPU.<br>
> > ><br>
> > ><br>
> > ><br>
> > > Thanks & Regards,<br>
> > ><br>
> > > Logeswari.<br>
><br>
><br>
><br>
> --<br>
> Please Donate to <a href="http://www.wikipedia.org" target="_blank">www.wikipedia.org</a><<a href="http://www.wikipedia.org" target="_blank">http://www.wikipedia.org</a>><br>
<br>
> --<br>
> Linux-audit mailing list<br>
> <a href="javascript:;" onclick="_e(event, 'cvml', 'Linux-audit@redhat.com')">Linux-audit@redhat.com</a><br>
> <a href="https://www.redhat.com/mailman/listinfo/linux-audit" target="_blank">https://www.redhat.com/mailman/listinfo/linux-audit</a><br>
<br>
<br>
- RGB<br>
<br>
--<br>
Richard Guy Briggs <<a href="javascript:;" onclick="_e(event, 'cvml', 'rbriggs@redhat.com')">rbriggs@redhat.com</a>><br>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat<br>
Remote, Ottawa, Canada<br>
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545<br>
</blockquote></div><br><br>-- <br>Please Donate to <a href="http://www.wikipedia.org">www.wikipedia.org</a><br>