On 2 sept. 2010, at 21:07, Jeroen Geilman wrote: >> Theses days I've got a lot of warning in postfix logs like this one: >> >> smtp/smtpd[91607]: warning: timeout talking to proxy 127.0.0.1:10024
> Why ? What is amavis doing at that moment ? not sure, but probably trying to end a +250 second analysis > More likely an *amavis* problem. 25 seconds just to greet the client is > insane. you're right. I was thinking may be a mis-configuration of postfix could cause a delay here too, but it makes no sense. I was pretty sure (90%) it's an amavisd related problem, but as explained in the intro, I wanted to make really sure my postfix settings are not to blame before going to the hassle of debugging amavisd. > Also, 21 seconds for an AV scan is rather long - this kind of checking is > best left to after-queue filters. A normal full amavis transaction last in general from 0.3 sec to 3 sec. The log I've sent is for an abnormal case, But I've had about 6 hours of this abnormal behavior yesterday. The server is in production since May, and I've had this kind of trouble 3 or 4 times. > Let's revisit your specs: > > FreeBSD 7.x in VMWare Virtual Machine, running on top of a 6 blades HP > chassis, 4Go RAM and 2 CPUs for the VM, > disk provided by an FC SAN (big array of FC disks). > > ONE amavisd instance can consume up to 60~80 MB of private memory; times 80, > this means you're using 6.4 GB of memory you _don't actually have_. nop, it's mostly shared memory here, With 80 amavisd process, I've still 2GB RAM free, and absolutely no swap. With 120 amavisd process and a max of 120 smtpd, I still have more than 1.5 MB of free RAM, and no swap. > Also, to RUN those 80 amavis threads, I would start with at least 4 cores. I do agree about cores. The VM what tuned for 30-40 amavisd, I should double the CPU, or remove amavisd and smtpd processes. I think I'm going to remote amavisd/smtpd processes. I've found out few hours after sending my question here that updating few perl modules could be the solution to my problem. I'm writing "could be", because I'm still not sure it's THE solution. After updating few perl modules (including NET::Socket) and restarted amavisd, it immediately started to work great. It does not guaranty it will not break under load again. >> Does the smtpd_client_connection_count_limit include the Proxy connexions? > > Um - whut ? > You're specifying smtpd_client_connection_count_limit on the *incoming* smtp > server. > Amavis doesn't talk to the incoming smtp server. yep, very silly question. I've realized how wrong I was few minutes after posting. > >> In an attempt to prevent "smtp-liste" to "eat" every possible connexion to >> "smtp" during a local emailing, I've set it's >> smtp_destination_concurrency_limit to 1, so that other more legitimate >> clients (30000 physical users) can still send emails during a local emailing. >> > > I have no idea what this means - you're limiting the *sending* of mail so > that your clients - for whom postfix *receives* mail - aren't bottlenecked ? I've made a mistake here, it should read: "In an attempt to prevent "smtp-liste" to "eat" every possible connexion to "MAILGW" during a local emailing". Both "smtp" and "smtp-liste" postfix instances are sending local domain emails to "mailgw", "smtp-liste" send huge bursts of emails (like 30000 recipients in 2-3 minutes), and it can greatly impact normal email delivery. So I throttle "smtp-liste" so that physical users emails posted via "smtp" are not delayed by a (useless) corporate emailing. Thank you very much for your reply Patrick PRONIEWSKI -- Administrateur Système - SENTIER - Université Lumière Lyon 2
smime.p7s
Description: S/MIME cryptographic signature
