-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2016-06-22 at 04:22 +0200, Carlos E. R. wrote:

On 2016-06-21 17:50, Yamaban wrote:

...

for your goal, I'd try the following: $min_servers = 1 $min_spare_servers = 1 $max_spare_servers = 2 $max_servers = 16

Seems logical. I'll try.

Worked a charm :-) Also needs adjustment in /etc/postfix/master.cf. I have now (not tested yet): smtp-amavis unix - - n - 16 lmtp -o lmtp_data_done_timeout=1200 -o lmtp_send_xforward_command=yes -o max_use=20 (I had 10 in there). - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAldqBIwACgkQtTMYHG2NR9XF7gCgkmwh0sX9YNoGWmw/RO5E6YPM XegAn1C5+SRJmiH5NdSG3CUzPG9+ZshE =2eCD -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2016-06-21 18:05, Per Jessen wrote:

Carlos E. R. wrote:

...

The problem is that amavis is slow, mostly because of online tests and time outs. It has to wait. So I increase the number of children (cpu load is low). But this takes ram; 8 GiB is no longer a big ammount.

Your system can really gobble up that much RAM doing spam-filtering?

Well, it is actually my main desktop machine. Many Firefox tabs, thunderbird, some jave apps, LibreOffice... all large applications. I just try to get some back, and amavis is a low hanging fruit :-)

My typical production server is also 8Gb, but rarely goes past 2-3Gb. Usually the clamAV database is the biggest user, spamd never uses a lot. (we don't use amavis, but a combination of spamc/spamd plus clamav).

clamd is a heavy user of ram, too. Number five in "top" display: PID USER PR NI VIRT RES SHR SWAP S %CPU %MEM TIME+ COMMAND 28517 cer 20 0 1533080 288892 33964 176336 S 0,000 3,526 89:19.09 thunderbird-bin 19735 cer 20 0 4061456 213736 5072 254632 S 0,000 2,609 32:20.97 java 19683 cer 20 0 6638024 180512 7824 35528 S 0,000 2,203 0:30.24 soffice.bin 10892 root 20 0 610860 172124 25296 197392 S 0,993 2,101 183:50.00 X 3581 vscan 20 0 1126492 143180 1240 216660 S 0,000 1,748 7:54.73 clamd 8708 cer 20 0 471428 132188 2252 26064 S 0,662 1,613 15:59.62 kwalletd 19916 cer 20 0 399092 114776 5792 0 S 0,000 1,401 0:43.06 acroread -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2016-06-22 07:40, Per Jessen wrote:

Carlos E. R. wrote:

...

clamd is a heavy user of ram, too. Number five in "top" display:

I use my own threaded clamd, it only uses about 400Mb including the sanesecurity signatures.

LOL. Do you realize that 400Mb is a lot? :-)) In my case, after recovery from hibernation, it seems to be totally swapped out: 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 SHR > RES. VIRT is not actual memory, I understand. If it is not swapped out and I understood it incorrectly, it is a waste. I might disable it completely, amavis can detect executables on its own. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2016-06-22 13:44, Per Jessen wrote:

Carlos E. R. wrote:

...

On 2016-06-22 07:40, Per Jessen wrote:

...

Carlos E. R. wrote:

...

...

clamd is a heavy user of ram, too. Number five in "top" display:

I use my own threaded clamd, it only uses about 400Mb including the sanesecurity signatures.

LOL. Do you realize that 400Mb is a lot? :-))

Well, in this context not really. There's plenty of memory on the machine.

I know, I know. It's a kind of joke. How much did the initial PC had, was it 512K or 512M? Sorry, I have a headache, filling tax forms. Can't remember. (Googling). Ok, less than one megabyte. 400MB is a lot :-))) Seriously, I think that clamd should free that ram when iddling or waiting, and request it when really needed.

...

If it is not swapped out and I understood it incorrectly, it is a waste. I might disable it completely, amavis can detect executables on its own.

clamav does a bit more than that. A attack with an actual executable is quite rare these days.

True... But this is Linux, I don't pick files on Windows the few times I use it. Actually, I have received a few emails with malware that clamav does not detect. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2016-06-23 08:37, Per Jessen wrote:

Carlos E. R. wrote:

640kb. Sorry, I missed your joke. Yeah - compared to the memory sizes of yesteryear, 8Gb in a desktop is another world altogether.

Yep.

...

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. 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.

...

True... But this is Linux, I don't pick files on Windows the few times I use it. Actually, I have received a few emails with malware that clamav does not detect.

Same here, every day. The sanesecurity databases are good for a lot of that, but some still get through. A lot of it isn't really "malware" either - just links to website with malware etc.

Hit ratio is about 50% here. I mean, 50% is not detected. And the total malware may be five per month... It was much more some years ago. Probably the ISPs are filtering. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

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)

On 2016-06-23 18:36, Per Jessen wrote:

Carlos E. R. wrote:

...

...

...

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.

You seem to want to have your cake and eat it :-) You want fast scanning, but you don't want clamd to keep the database in memory to enable that. Starting and stopping before and after each batch is perhaps a solution. Not sure you can make that work with xinetd, it usually starts a new instance per request.

:-) Well, yes, I would want the scanner to load with the first post, and free the memory or die 5 minutes after idling. I can do it manually, with a script that starts it, then calls fetchmail. Except that amavis also scans emails on send, so no, I can't do it. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)