Carlos E. R. wrote:
On 02/09/2019 17.36, Per Jessen wrote:
Carlos E. R. wrote:
I tried the same on my own clamd daemon (custom written, but same idea). Startup took just about 9 minutes, the first few scans took up to 35sec, but then it seems to drop to 1-2 seconds. That's easily 10 times more than normal, which isn't good. Sometimes processing time shoots up to 5 or 10. Still fairly minimal impact - I guess the numbers I'm seeing might be schewed as the system has plenty of memory.
Yes, I can accept this impact. Now ram usage is just beneath 400M. I'll try later something: find out the cgroup entry for memory limit and change it "brute", ie, after start.
memory.limit_in_bytes
See if I can manage to drop the mem use to minimal on demand, then back to "normal" limit. This would allow a much faster response, and recover 800MB when I want it. If this works, I may be able to script it into the mail fetch script.
I think you can probably find a fairly low "working-set" that'll give you a decent response in 99% of cases.
I'm considering alternatives, like hacking amavis so that it "unswaps" clamav before calling it, then sets the limit to 200 afterwards. Or doing it manually. Or a cronjob: if clamav is not busy (below 1%) force it to swap, then rever after a minute (but it will stay swapped out, I hope).
Sounds a bit over-engineered.
However, the reason you're not seeing your clamd reduce memory usage without this memory limit is that your system simply has sufficient memory. I took a look at my test system cluster, four virtual machines with only 1.2Gb each. On those clamd is using less than 500Mb, with no cgroup memory limit and no changed swappiness.
No, this is not so.
In my example, clamd seems to behave the way you want though.
Several applications, like Thunderbird and Mozilla, are starving and they swap. I prefer clamav to go to swap than others, simple as that.
There is probably a way of prioritising that. I wonder if processes running with privileged userids are given higher priority? You could try running clamd with a non-privileged userid. -- Per Jessen, Zürich (15.5°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org