On Thu, Dec 09, 2010 at 02:59:56PM -0500, Dave Brodin wrote:

> Old server - Dual 2.8 GHz Xeon processors with 4 GB RAM
> New server - Dual 2.8 quad-core processors with 8 GB RAM
>
> Things run fine on old server, but hardware is starting to fail.  When we 
> start postfix on the new server and everything runs fine for about 5-10 
> minutes as mail starts flooding in.  CPU idle time is almost 100% and mail 
> is being processed just fine.  All of sudden, the CPU load starts to rise 
> quickly, the smptd active processes start consuming large amounts of 
> processor time, and the active queue starts to grow out of control.

Can you report specific measurements that show that lots of CPU is
consumed in smtpd(8)? Does logging indicate any change in the pattern of
mail coming in or going out? Progress is only possible if you can report
detailed quantitative non-anecdotal measurements.

> This it the last version of main.cf (non-default parts).  We tried lots of 
> changes trying to get it to work.
>
> alias_database = hash:/usr/local/etc/postfix/aliases, 
>       hash:/usr/local/etc/postfix/aliases.majordomo
> alias_maps = hash:/usr/local/etc/postfix/aliases, 
>       hash:/usr/local/etc/postfix/aliases.majordomo

You could try "cdb", instead of "hash". Which version of Berkeley DB
is this?

        http://www.postfix.org/CDB_README.html

> bounce_queue_lifetime = 1d

A bit aggressive.

> default_process_limit = 500
> local_recipient_maps = $alias_maps unix:passwd.byname

How bit is the "passwd" file? What's in nsswitch.conf or
equivalent for "passwd"?

> maximal_backoff_time = 4h

Fine.

> maximal_queue_lifetime = 2d

A bit aggressive.

> minimal_backoff_time = 30m

A bad idea, the default setting scales better.

> mydestination = $myhostname, localhost.$mydomain, $mydomain
> myorigin = $mydomain
> relay_domains = hash:/usr/local/etc/postfix/relay

You may want to set "fast_flush_domains = " if you don't support ETRN.

> smtpd_tls_security_level = may
> smtpd_tls_cert_file = /usr/local/certs/smtpd.pem
> smtpd_tls_key_file = $smtp_tls_cert_file
> smtpd_tls_loglevel = 1
> smtpd_tls_received_header = yes
> smtpd_tls_mandatory_protocols = TLSv1

Enabling TLS session caching may be a good idea, recommended database
type for that is "btree".

> smtpd_client_restrictions =
>       check_client_access hash:/usr/local/etc/postfix/client_access

Could try "cdb" instead of "hash".

> smtpd_recipient_restrictions =
>       reject_unknown_sender_domain,
>       check_sender_access hash:/usr/local/etc/postfix/sender_access,

Poor placement, see:

    http://www.postfix.org/SMTPD_ACCESS_README.html#danger

>       check_recipient_access hash:/usr/local/etc/postfix/recipient_access,
>       permit_mynetworks,
> #     reject_rbl_client sbl-xbl.spamhaus.org,

You really should use a local mirror of Zen, sign-up for a SpamHaus
data feed.

>       permit_sasl_authenticated,

Same place as permit_mynetworks above the RBL if you ever add one.

>       reject  

Much better would be:

smtpd_recipient_restrictions =
        ... Filters for trusted clients that may REJECT some traffic ...
        permit_mynetworks,
        permit_sasl_authenticated,
        reject_unauth_destination,
        ... Sender filters ...
        ... Additional recipient filters ...
        ... RBL checks ...


> virtual_maps = hash:/usr/local/etc/postfix/virtual

Consider "cdb".

> transport_maps = hash:/usr/local/etc/postfix/transport

Consider "cdb".

> # About 2 Gigs
> mailbox_size_limit = 2048576000

Not a good idea. Mailboxes of this size need to be maildirs.

-- 
        Viktor.

Reply via email to