[clamav-users] Memory usage going up until OOM

[Arjen de Korte]

Citeren PenguinWhispererThe via clamav-users <clamav-users at lists.clamav.net>:

> Hi,
>
> I have a webserver with 4GB of memory that also functions as a mailserver.
> The mail volume is rather low (perhaps a few hundred mails/day).
> Almost every day around the same time I get a swap usage warning and once
> in a while clamd crashes because it has no more swap space available
> blocking mails from being processed.
>
> Right now it uses about 1.3GB and all is fine. I'm using FreeBSD. I'm
> trying to see the logic why every day around the same time clamd decides to
> need so much more memory. It's not like it needs it to process the emails.
>
> I've searched and read that clamd uses a lot of memory (30% is indeed quite
> a lot). But nowhere I see these kinds of numbers (multiple gigabytes).
> Having it use 60% memory (at least 2.3GB when it crashes) is getting
> ridiculous. Since all mails are being processed just fine when clamd uses
> 1.3GB I don't want to just increase the memory as it might start using 60GB
> at some point for no clear reason.
>
> I didn't modify cronjobs recently so I'm unclear on why this seems to be a
> periodic thing. I had it like weeks in a row at around 15:45. Then it
> seemed to have switched to 17:45 and had it now once at 19:45. There seems
> to be this 2 hour change in it or it's something that happens every 2 hours
> and circumstances get "just right" later and later.
>
> Anyone experienced the same? Knows what's going on? Has a solution to this
> (not looking for "don't run clamAV as a daemon")?
>
> Thanks in advance!

This is most likely due to loading the new signature database after  
downloading. Previously, clamd would drop the existing database before  
loading the new one. But this changed in version 0.103.0 as this to  
load the new one first before dropping the old one. See the following  
from /etc/clamd.conf which explains why and what you can do to change  
back to the previous behaviour:

# Enable non-blocking (multi-threaded/concurrent) database reloads.
# This feature will temporarily load a second scanning engine while scanning
# continues using the first engine. Once loaded, the new engine takes over.
# The old engine is removed as soon as all scans using the old engine have
# completed.
# This feature requires more RAM, so this option is provided in case users are
# willing to block scans during reload in exchange for lower RAM requirements.
# Default: yes
#ConcurrentDatabaseReload no