[Postfixbuch-users] Speed-Problem

[Frank Fiene]

Am 04.02.2012 um 19:46 schrieb Peer Heinlein:

> Am Freitag, 3. Februar 2012, 16:14:27 schrieb Frank Fiene:
> 
> 
> Moin,
> 
>> Also hat der interne Mailserver in 10 Minuten 4000 Mails in meinen
>> Postfix-Server gekippt. Der Postfix hat dann vier Stunden gebraucht,
>> um 2000 Mails zuzustellen.
> 
> Tja, da müßte man sich halt jetzt die Symptome anschauen. Standen die 
> Mails in der deferred? Wenn ja: Weswegen? Waren die noch alle in der 
> incoming (also mit * versehen?). Wieviele SMTP-Prozesse waren aktiv? Vor 
> allem: Wurden irgendwelche Gegenstellen per dead peer detection komplett 
> rausgenommen?

Wie du schon sagtest, Beweise vernichtet. Ich habe nur noch die Logs.

>> Nachdem ich denn ein "postsuper -r ALL" gemacht habe, waren alle
>> Mails innerhalb von 2 Minuten verschwunden.
> 
> Was du eigentlich erreichen wolltest ist ein "postfix flush". Du 
> solltest dieses Kommando nehmen und nicht etwa postsuper -r. 
> 
> Ersteres setzt alle "Straf-Wartezeiten" auf Null und bringt umgehend 
> alle Mails zur Auslieferung. Letzteres requeued alle E-Mails, kippt sie 
> also über pickup/maildrop neu ab, so daß sie aufwändig (!) neu von 
> cleanup bearbeitet und ggf. auch gefiltert werden müssen. 
> 
> Die werden dann am Ende natülich auch mit Null Wartezeit ausgeliefert, 
> klar. Ziel erreicht. Aber das ist dann ungefähr so filigran wie mit 'nem 
> Rambock die Haustür aufzumachen, nur weil man den Schlüssel tief im 
> Rucksack verbuddelt hat.

Jaha, habs verstanden! ;-)

>> Jetzt wundere ich mich, dass der die nicht sofort wieder alle
>> verschickt hat. Ist das irgendeine Schutzfunktion, die ich für Mails
>> von innen nach außen deaktivieren kann? Da stehen jetzt immer noch
>> 100 Leichen in der mailq, die normalen wie Mailbox Full oder einfach
>> Timeout.
> 
> Tja. Mit welcher Begründung stehen sie in der Queue? Was findet sich zu 
> diesen Queue-IDs denn im Logfile?
> 
>> Was kann das sein? Das dürfte doch wohl kein Problem sein, der Server
>> hat die Mails auch so schnell angenommen!!1!11!! Internet-Leitung
>> war auch normal schnell, zu der Zeit so 30MBit, das ist eine
>> 155MBit-Leitung!
> 
> Naja, die Beweise hast Du gerade vernichtet. Schau ins Log zu den 
> betreffenden E-Mails (oder poste was). Gewisse Sachen wie dead peer 
> detection jedoch lassen sich da kaum nachvollziehen, weil sie eben 
> bewirken, daß die tote Gegenstelle NICHT angesprochen wird für eine 
> gewisse Sperrzeit und dann steht auch nichts im Log.


Also laut den Logs wurden alle Mails wie folgt in die Queue gekippt:

Feb  3 11:45:14 mail postfix/smtpd[9031]: 3BFB32F7E0A: client=unknown[10.110.1.135]
Feb  3 11:45:14 mail postfix/cleanup[9245]: 3BFB32F7E0A: message-id=<OFE333E119.C1FBB8EC-ONC1257999.003AE285 at veka.com>
Feb  3 11:45:14 mail postfix/qmgr[1545]: 3BFB32F7E0A: from=<info at veka.com>, size=57970, nrcpt=1 (queue active)

Die ersten Mails wurden auch sofort zugestellt, ich habe mir exemplarisch ein paar aus den 4000 rausgesucht.

Nach ein paar hundert Mails gab es 5 Minuten Delay: conn_use=6, delay=624, delays=0.24/617/0/6.7, das wurde natürlich immer mehr: conn_use=7, delay=2971, delays=0.27/2963/0/7.2, conn_use=5, delay=2959, delays=0.22/2952/0/6.6

Kann es an der Anzahl an smtp-Prozessen liegen, die freigegeben sind?
Sind das im Standard 100?


Viele Grüße!
Frank
-- 
Frank Fiene / IT-Services
Internet Services / IT-Security
Fon: +49 2526 29-6200
Fax: +49 2526 29-16-6200
mailto: ffiene at veka.com
http://www.veka.com
PGP-ID: 20419C64
PGP-Fingerprint: 93FB 5525 88C0 8F40 E7FD  EAB5 BBB4 435F 2041 9C64

VEKA AG
Dieselstr. 8
48324 Sendenhorst
Deutschland/Germany

Vorstand/Executive Board: Andreas Hartleif (Vorsitzender/CEO),
Dr. Andreas W. Hillebrand, Bonifatius Eichwald, Elke Hartleif, Dr. Werner Schuler,
Vorsitzender des Aufsichtsrates/Chairman of Supervisory Board: Ulrich Weimer
HRB 8282 AG Münster/District Court of Münster