Re: [AMaViS-user] timeout after data (amavisd-new-20030314-p1)

[Ralf H. <Ral...@ch...>]

* Mark Martinec <Mar...@ij...>:

> The timeout on connection from Postfix is not noticed by amavisd-new,
> and it carries out its job further on. This is a pitty, but Perl module
> Net::SMTP does not offer timeout capabilities during data transfer.

Ah, what a shame.

> It took 13 minutes(!) to feed checked mail back to Postfix.
> This is way too much even for a fat mail (6.92 Mb) like this one.

I thought so.

> | May  2 14:57:03 RELAY amavis[4035]: (04035-06) TIMING [total 801729 ms]
> | - SMTP EHLO: 4 (0%), SMTP pre-MAIL: 5073 (1%), SMTP pre-DATA-flush: 7 (0%),
> | SMTP DATA: 2563 (0%), body hash: 365 (0%), mime_decode: 5729 (1%),
> | get-file-type: 38 (0%), get-file-type: 13 (0%), get-file-type: 13 (0%),
> | decompose_part: 8 (0%), decompose_part: 1 (0%), decompose_part: 1 (0%),
> | parts: 0 (0%), AV-scan-1: 893 (0%), fwd-connect: 24 (0%),
> | fwd-mail-from: 18 (0%), fwd-rcpt-to: 3 (0%), write-header: 10 (0%),
> | fwd-data: 767290 (96%), fwd-rundown: 19665 (2%), unlink-3-files: 11 (0%),
> |           ^^^^^^
> | rundown: 0 (0%)
> 
> It took 767.290 s (12.8 minutes) to transfer 7 Mb of data back to Postfix!
> This machine is really badly overloaded, either with disk i/o,
> or with too many content scanning processes. 

I shall have him check that.

> Move /var/amavis to a separate disk from Postfix queue disk, keep
> number of content filtering processess to a reasonable level (2-3 per
> CPU is a good start), buy a faster machine.

We'll see what is appriopriate.

-- 
Ralf Hildebrandt (Im Auftrag des Referat V a)   Ral...@ch...
Charite Campus Mitte                            Tel.  +49 (0)30-450 570-155
Referat V a - Kommunikationsnetze -             Fax.  +49 (0)30-450 570-916
AIM: ralfpostfix