Re: Odd memory usage in auditd
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