Odd memory usage in auditd

[Steve Grubb]

On Monday, October 11, 2010 11:50:53 am Ross Kirk wrote:
> > I seem to recall something about disk flushing causing auditd to look
> > like its the culprit. Do you have barriers enabled on ext3? You might also
> > try setting the flushing to something else like none and see if that does
> > anything.
> 
> Currently barriers are not enabled as it wasn't something I was aware of.
> However it does sound like something I may well want to be enabled so I
> will give the various flush settings a try and see if the barrier option
> affects anything. 

Well, I was thinking that if you had it enabled that perhaps things were 
getting backed up.


> So if auditd is not the culprit what do you suspect the
> problem is?

Yes. I think under some situations because the flushing is delayed, the kernel 
memory accounting associates the buffers not yet flushed to disk with the 
process that originates the request. I don't think that is fair, but seems to 
happen.

 
> > Try playing with the disk flushing and let us know how that works out.
> > There are no known memory leaks in recent version of auditd. I try to keep
> > malloc down to a minimum to prevent this and memory fragmentation to creep
> > in.
> 
> With;
> *  flush = none Completely different behaviour from previous, memory usage
> never changed for my entire test run 
> *  flush = data No increase in memory usage at all
> *  flush = sync No increase in memory usage at all
> 
> Changing the ext3 barrier setting didn't make any changes to the above
> results nor to the behaviour I saw when "incremental" was set.
> 
> Well as the other settings are better behaved I can change to using "data"
> without any problems I believe. Arguably this is probably a better choice
> for me anyway!
> 
> Thanks for your help!

Sure.

-Steve