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 -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
