Re: mail relay + sendmail/postfix

From: Jesper Skriver (none@jesper--skriver.dk.lh.bsd-dk.dk)
Date: Fri 22 Mar 2002 - 22:14:29 CET


Date: Fri, 22 Mar 2002 22:14:29 +0100
From: Jesper Skriver <none@jesper--skriver.dk.lh.bsd-dk.dk>
To: bsd-dk@bsd-dk.dk
Subject: Re: mail relay + sendmail/postfix

On Fri, Mar 22, 2002 at 07:11:09PM +0100, Jacob Nielsen wrote:
> Hejsa,
>
> Jeg har sat et mail relay for en kunde som skal sende xxx tusind mails helst
> så hurtigt så muligt.

Et sådant setup vil være disk I/O bundet ...

> Her er maskinens setup;
> 2x P3 550
> 2x 256 mb ram
> 1x Adaptec 29160
> 1x ibm 160mb/sec 15k rpm
>
> Resultat;
> FreeBSD 4.5-STABLE + sendmail = 4-8 mails/sec.
> FreeBSD 4.5-STABLE + postfix = 15 mails/sec.
> Debian Linux + postfix (ext2 & ext3) = 25 mails/sec.

... og Linux er derfor hurtigere, da den pr. default mount'er sine
filsystemer async.

På FreeBSD bør du sikre dig at du har softupdates enablet, samt har
UFS_DIRHASH i din kernel, det vil hjælpe markant, efterfølgende bør
du så tillade DIRHASH at bruge mere end default memory, f.eks. ved at
indsætte følgende i /etc/sysctl.conf

vfs.ufs.dirhash_maxmem=16677854

> Kunden connector med en Microsoft smtp som kan levere
> min. 50mails/sec. (jaja sygt men ...) Denne klient connector mange
> gange samtidigt! Er ikke klar over _hvor_ mange, men mange.

Så mail kommer ind via SMTP, fint.

> Er det overhovedet muligt at få dette højere op på nogle måde og i
> såfald hvordan? På FreeBSD maskinen hævede jeg NMB_CLUSTER til 131k
> i kernel og fjernede naturligvis al understøttelse af hardware som
> ikke findes i maskinen. Dette burde være rimeligt optimalt. Det samme
> gjorde jeg på Debian Linux'en.
>
> Jeg forsøgte at tweake postfix en smule, bla.
> default_process_limit. Faktisk havnede maskinen på et load average på
> 300+ da jeg satte den for højt :) så den skal man lige være varsom
> med. Jeg forsøgte alt fra 10 til 1000. Default er 50. Den står nu til
> 200. Kører rimeligt pænt. Når kunden smider sine mails til relay'et,
> havner den kun op på 100-150 i load average :)

En anden ting du kan ændre er

hash_queue_depth = 3
hash_queue_names = defer, incoming, deferred

Men det er der ingen grund til at gøre hvis du enablet DIRHASH som nævnt
ovenfor.

En anden mulighed er at de mails som ikke ummiddelbart kan afleveres,
sendes til jeres ISP's smarthost, da en væsentlig del af loadet skyldes
mails som ikke umiddelbart kan afleveres.

fallback_relay = smtp_server.hos.isp.dk

Hvis du gør det, så er der ingen grund til at hash'e deferred
directoriet ovenfor.

Du kan så også ændre TCP timeout til f.eks. 30 sekunder, så du
ikke har processer der hænger i lang tid i forsøget på at connecte
til mailservere der ikke er oppe, det giver kun mening hvis du har
fallback_relay konfigureret.

smtp_connect_timeout = 30s

og evt. disse timeout's også

smtp_helo_timeout = 60s
smtp_mail_timeout = 60s
smtp_rcpt_timeout = 60s
smtp_quit_timeout = 60s

Har du mange mails til de samme domains, hvis ja, så kan du også
øge denne

smtp_destination_concurrency_limit = 10

Default er 10, 20 var en mulighed

Mht. max processes, så skal du sørge for at begrænse antallet af
connections ind i boxen, så jeg ville gøre noget ala

default_process_limit = 200

evt. lidt højere

Men så begrænse hvor mange smtpd (indkommende mail) processer der kører
på boxen, sådan at du sikrer at der ikke bliver for stor en kø på boxen.

i master.cf ændrer du linien

smtp inet n - n - - smtpd

til

smtp inet n - n - 50 smtpd

Som gør at der maksimalt vil være 50 smtpd processer

> Desuden har jeg lavet en dns caching server på localhost, for at
> formindske (i hvert fald lidt) mine dns lookups. Dette ser ud til at
> have hjulpet lidt, men ikke meget.
>
> Her er så mit spørgsmål. Er der nogle andre der har lavet lignende
> sindsyge løsning hvor de er kommet højere på i mails/sec og i såfald
> hvordan? Jeg er sikker på en extra disk vil hjælpe lidt også til f.eks
> /var/spool/postfix.

Det vil helt sikkert hjælpe, disk I/O kommer af 2 ting, logging samt
spool, så en hurtig disk til spool vil hjælpe meget.

> Kan det også være et fork() kontra thread problem?

Næppe, postfix bruger ikke threads, men processer som lever relativt
lang tid.

> Eller måske en helt anden løsning ... ?
>
> Ville sgu være kewl hvis nogle kunne komme med nogle forslag :)

/Jesper

-- 
Jesper Skriver, jesper(at)skriver(dot)dk  -  CCIE #5456
Work:    Network manager   @ AS3292 (Tele Danmark DataNetworks)
Private: FreeBSD committer @ AS2109 (A much smaller network ;-)

One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them.



This archive was generated by hypermail 2b30 : Wed 15 Nov 2006 - 18:24:19 CET