On 01/09/2019 09.38, Per Jessen wrote:
Carlos E. R. wrote:
Photo using top, sort by memory, this instant:
PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 21395 cer 20 0 3402620 782716 85432 166280 S 69,35 9,591 61:58.83 Web Content 1096 cer 20 0 3688736 767644 104104 0 S 2,976 9,406 19:05.04 thunderbird-bin 3938 vscan 20 0 999648 725460 2628 17856 S 0,000 8,889 8:09.22 clamd .................................*******
0.7 GB of RAM! I will have to uninstall it. Las time I looked, it was half a gigabyte.
And it is set with swapiness of 100...
A couple of comments
- increasing swappiness will only create more work for your system and increase latency in processing.
Which is totally acceptable. It is already set to 100 for that process, and still it does not swap out on its own :-( Current status, after coming from hibernation this morning: PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 3938 vscan 20 0 999648 28740 2924 715764 S 0,000 0,352 8:09.72 clamd As you can see, now is almost totally swaped out. No issues. It just increased the used time some centiseconds. I will now send an email to myself on another computer, and check. <2.6> 2019-09-01 14:08:45 Telcontar postfix 4031 - - 482C33213B5: from=<cer@Telcontar.valinor>, size=892, nrcpt=1 (queue active) <2.6> 2019-09-01 14:08:45 Telcontar amavis 30621 - - (30621-03) ho0PUkymM_pr FWD from <cer@Telcontar.valinor> -> <cer@isengard.valinor>, BODY=7BIT 250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 482C33213B5 <2.5> 2019-09-01 14:08:45 Telcontar amavis 30621 - - (30621-03) Passed CLEAN {RelayedInbound}, [127.0.0.1] <cer@telcontar.valinor> -> <cer@isengard.valinor>, Message-ID: <20190901120845.19CD43213B4@telcontar.valinor>, mail_id: ho0PUkymM_pr, Hits: -, size: 455, queued_as: 482C33213B5, 148 ms <2.6> 2019-09-01 14:08:45 Telcontar postfix 6145 - - 19CD43213B4: to=<cer@isengard.valinor>, orig_to=<cer@isengard>, relay=127.0.0.1[127.0.0.1]:10024, delay=0.21, delays=0.02/0.04/0/0.15, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 482C33213B5) <2.6> 2019-09-01 14:08:45 Telcontar postfix 4031 - - 19CD43213B4: removed <2.6> 2019-09-01 14:08:45 Telcontar postfix 4031 - - 19CD43213B4: removed <2.6> 2019-09-01 14:08:45 Telcontar postfix 6150 - - 482C33213B5: to=<cer@isengard.valinor>, relay=isengard.valinor[192.168.1.16]:25, delay=0.21, delays=0/0.04/0.11/0.05, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 796FBA2131) As you can see, no impact at all. PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 3938 vscan 20 0 999648 28892 2924 715596 S 0,000 0,354 8:09.73 clamd Same thing. One centisecond more, almost same swap amount. Maybe clamd is only used on mail receive, and that is a manual operation when I call fetchmail. Maybe the clamd daemon is awakened periodically when the database is freshened. I do not understand why with a swapiness of 100 for that process, it doesn't swap out when it is not being used for hours. :-(
- amount of memory used depends on the signature files you are using and somewhat on whether you are on 32bit or 64bit. On 32bit, I see 700Mb used, on 64bit I see 1Gb.
- the amount memory used by clamd will continue to grow, albeit slowly.
:-(
Options -
- as you propose, don't use clamd, just live with the risk.
Which is probably nil, being on Linux. I can manually scan attachments.
- run clamscan on demand instead, if you don't care much about the latency and the extra work.
I failed at configuring this.
- run clamd on a another machine
I failed at doing this. No idea how to do it, unless I move the entire amavis. The other machine has free memory but the CPU is way less powerful.
- limit the signature files you are using or reduce their size. I don't know how feasible the latter is, but signatures in the database do have timestamps.
The only thing that worries me would be scanning PDF and other document types. Win executables I don't expect any and amavis can handle them on its own. If it were possible to unload all exe signatures... Or perhaps there is another antivirus we can use :-? -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)