From: "Jesper Louis Andersen" <none@jlouis--mongers.org.lh.bsd-dk.dk> Date: Wed, 28 Jan 2004 18:47:35 +0100 To: bsd-dk@bsd-dk.dk Subject: Re: qmailqueue
Quoting Fedder Skovgaard (fedder-public@skovgaard.dk):
> > Hvorfor er de tre strategier qmail laver retry efter "notoriskt dumme"?
> > http://cr.yp.to/qmail/faq/efficiency.html
>
> Oprindeligt syntes jeg det var en så afstumpet kommentar at den slet ikke
> burde værdiges med et svar. På den anden side er det jo synd for staklen at
> han går rundt og er så uoplyst. Det var pænt af dig Magnus.
Jamen, jeg har skam laest hvad DJB skriver om sin qmail. Paa den anden
side har jeg ogsaa benyttet programmet i et 40k/doegn mailsetup. Jeg
gaar ud fra at du henviser til kvadratisk back-off. Det er fornuftigt
nok og samtlige mailere der er vaerd at snakke om goer det. At dens
queue skalerer er heller ikke en specielt imponerende feat, men det er
dog interessant i forhold til det at man kan have mange mails haengende.
Naar jeg siger at qmail er dum til at manage sine queues, saa skyldes
det 2 vaesentlige problemer jeg er stoedt paa i tidens loeb.
Det foerste er at skruer man concurrencyremote op til 120 og har man
pludselig 10000 mails der skal til en 256Kbit forbindelse i USA, saa
har man samtlige 120 delivery processes haengende mod den server proviso
at den accepterer samtlige connections. Note at dette er en stock
Qmail 1.03 uden nogen patches whatsoever. Andre mailere har en
destination concurrency limit saa det ikke kan ske og du sikrer fair
weighting af levering af post. Med SMTP Pipelining (som qmail ikke
understoetter AFAIR) kan du alligevel sagtens faa masser af fart paa
med 10 forbindelser parallelt mod den samme host.
Det naeste problem er at hvis man har opbygget sig en queue paa omkring
20.000 mails og skal levere denne, saa bliver den leveret i strict FIFO
orden. Det betyder at nye mails foerst leveres efter alle de andre er
blevet leveret. Andre mailere vaelger at ''splejse'' nye mails ind, saa
der hele tiden tages en gammel mail og en ny mail. Det giver mening, da
mails der ligger og venter ikke forventes at komme frem lige med det
samme. Om der gaar 5, 10, eller 15 minutter er ikke saa vaesentligt, men
hvis en bruger afsender en mail og han ikke ser den i den anden brugers
inbox paa under 15 sekunder, saa bliver han sur.
Qmails queue kan ikke taale at koere med softupdates. Det kan exims
heller ikke. Postfix' queue skulle kunne taale det. Jeg kalder det
daarligt design.
http://cr.yp.to/qmail/faq/reliability.html#filesystems
fsync() skulle gerne vaere synkron og atomar.
Det foerer saa til daarlig performance:
http://www.google.dk/search?q=cache:A4cBEUADJ_gJ:mandree.home.pages.de/postfix/vsqmail.html+softupdates+qmail&hl=da&ie=UTF-8
http://www.google.dk/search?q=cache:TvO9DANDZP0J:mandree.home.pages.de/postfix/bench2.html+softupdates+qmail&hl=da&ie=UTF-8
(Cached fordi den oprindelige side var vaek)
Den sidste ting jeg er stoedt paa med qmail der er kedelig er at der
ikke er nogen aekvivalent for local_recipient_concurrency limit i
qmail (som postfix har). Jeg har set 120 local delivery processes
haenge mod den samme procmail og derved totalt bremse alt lokal mail-
levering til samtlige 2000 brugere. Specielt naar den procmail skulle
time ud efter 15 minutter.
Et andet stort problem er at qmail er for soed. Al post til $domain
modtages gladeligt, der genereres en bounce message, der selvfoelgeligt
ikke kan afleveres fordi man modtog spam. Lad os bare sige at med 40k
mails i doegnet, saa bliver ens queue ikke mindre end 10k mails pga
disse bounces. Postfix afviser sikre bounces i doeren ved at sende en
5xx fejlkode tilbage og goere det til afsenders job at bounce. Det
holder den mailqueue ren. Specielt hvis du ogsaa konfigurerer den til
ikke at acceptere post fra domains den ikke kan lave DNS-opslag paa.
Saa er der alle de smaa annoyances. procmail/postfix/sendmail har et
saet af return codes, qmail har et andet. Der skal mindre kode til at
styre vores alias-maps i postfix end der skulle i qmail. Mulighederne
for at lave om paa hvilke programmer der koeres hvor er bedre i postfix.
Du har tarpitting by default. etc.
Saa jeg mener jeg kan paastaa at ''qmails queue er notorisk dum''.
Forstaa at qmail, sandsynligvis med vilje, springer over hvor gaerdet
er lavest en del steder og benytter brute-force til at loese problemet.
Det kan, alt efter stoerrelse af mailsystem, vaere en velsignelse
eller en forbandelse. Qmail er raafed til mindre sites med fornuftige
brugere. Den loeser sit job effektivt, der er aldrig fundet slemme fejl
i koden etc. Det irriterer mig at den vil installeres i /var, men det
kan man godt acceptere.
-- j.
This archive was generated by hypermail 2b30 : Wed 15 Nov 2006 - 18:24:35 CET