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. 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. -- Per Jessen, Zürich (16.8°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