I made a log of the memory usage:
Date/time STARTED ELAPSED %MEM VSZ RSS COMMAND
2008-02-06T23:10:01 22:12:25 57:36 10.6 74840 54708 clamd
2008-02-06T23:20:01 22:12:25 01:07:36 10.6 74840 54708 clamd
2008-02-06T23:30:01 22:12:24 01:17:37 11.7 80516 60308 clamd
2008-02-06T23:40:01 22:12:25 01:27:36 11.7 80516 60308 clamd
...
2008-02-07T00:10:01 22:12:24 01:57:37 11.7 80516 60308 clamd
2008-02-07T00:20:01 22:12:25 02:07:36 11.7 80516 60308 clamd
2008-02-07T00:30:01 22:12:24 02:17:37 21.1 132136 108192 clamd
2008-02-07T00:40:01 22:12:25 02:27:36 21.1 132136 108192 clamd
...
Comparing with /var/log/clamav/clamd.log, it looks like the increases happen
at the time of database reloads:
Wed Feb 6 23:22:33 2008 -> SelfCheck: Database modification detected. Forcing
reload.
Wed Feb 6 23:22:33 2008 -> Reading databases from /var/lib/clamav
Wed Feb 6 23:22:33 2008 ->
/var/spool/exim4/scan/1JMsf2-0003MD-L7/1JMsf2-0003MD-L7.eml: OK
Wed Feb 6 23:22:35 2008 -> Database correctly reloaded (206244 signatures)
...
Thu Feb 7 00:22:59 2008 -> SelfCheck: Database modification detected. Forcing
reload.
Thu Feb 7 00:22:59 2008 -> Reading databases from /var/lib/clamav
Thu Feb 7 00:22:59 2008 ->
/var/spool/exim4/scan/1JMtbR-0003Ui-5N/1JMtbR-0003Ui-5N.eml: OK
Thu Feb 7 00:23:01 2008 -> Database correctly reloaded (206247 signatures)
That looks a bit like clamav bug 736
(https://wwws.clamav.net/bugzilla/show_bug.cgi?id=736) to me. The development
team claims it's because of the way malloc/free works, and that the memory
eventually will be reused by future mallocs. I'm not sure that that is
consistent with what I'm seeing though.
I'll let it run now and see if the memory usage keeps increasing, or if it
tops out eventually.
As a last resort I can of course just restart the process every day, but
that's not a real solution.
--
Roel Schroeven
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
