On 2016-06-23 15:09, Per Jessen wrote:
Carlos E. R. wrote:
On 2016-06-23 08:37, Per Jessen wrote:
Carlos E. R. wrote:
Seriously, I think that clamd should free that ram when iddling or waiting, and request it when really needed.
It would be a waste of IO and really slow thjings down. clamd keeps the signature database in core to be able to produce fast responses.
Not really... when the daemon detects that it has no requests for some time (say, five minutes, one hour), free memory. Reload on the first request, for another interval.
Nope, I disagree. That's what the virtual memory manager is there to do. If nothing is being scanned, pages will be reclaimed as and when needed. When clamd needs to do a scan, they can be paged in. The application should not need to worry about that.
It does not happen. Look at top output: KiB Mem: 8192768 total, 5572716 used, 2620052 free, 290088 buffers KiB Swap: 34305004 total, 3544084 used, 30760920 free, 2305496 cached PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 3581 vscan 20 0 1193220 365684 6032 724 S 0,000 4,463 8:20.35 clamd Only 724K is swapped out. Last scan was an hour or two ago, and I need that memory for java applications and such. See the total used swap. It is only swapped out after hibernation - from yesterday: PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 3581 vscan 20 0 1192028 159116 1384 200920 S 0,000 1,942 7:55.83 clamd It is the same instance, same PID.
In my case, it is used a few times a day, or perhaps none. I could do a script to run fetchmail and previously load it.
Well, maybe for that situation it is an abuse of resources, but why bother with a daemon at all when your usage pattern is on-demand and infrequent? Just scan your mails straight from procmail, in particular if you're worried about resource usage.
If I scan from procmail, either I use clamd, in which case the situation is the same regarding memory usage, or I use clamav, which means loading it a hundred times, once per email. It takes a minute to scan a file, clamav is very slow to start up. No, I would need something to start and kill the daemon automatically before and after needed. Perhaps xinetd. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)