[lug-ld] Postfix

[Christian Boltz]

Hallo Michael, hallo Leute,

Am Samstag, 16. April 2011 schrieb Michael Diederich:
> 2011/4/16 Christian Boltz <lug-ld at cboltz.de>:
> > Am Freitag, 15. April 2011 schrieb Michael Diederich:
> Anstatt 50 hätten es 1000 sein sollen. Es war ein Newsletter an alle
> angemeldeten Benutzer.

Oha, das ist ein kleiner ;-) Unterschied.

Ich könnte jetzt eine interessante Geschichte von einem Kunden erzählen, 
der sich selbst versehentlich mit mehrere GB Mails, verteilt auf 
handliche 2 MB-Häppchen, bombardiert hat. Mir hat daran nur wehgetan, 
dass der empfangende Mailserver irgendwann dicht war und die mailq meine 
/var gefüllt hat ;-)
Sagen wir einfach so: Er war ziemlich dankbar, dass ich die restlichen 
Mails aus der Warteschlange gelöscht habe *g* - und er wird nie mehr aus 
einer foreach-Schleife heraus Mails versenden ;-)

> Ja, der Server ist virtualisiert und hätte 2GB zur Verfügung, die
> allerdings auch gebraucht werden (Anwendung, Datenbank usw.)

> Unter top war kein Prozess zu identifizieren. Der Apache war immer
> mal dabei, aber auch wenn ich mir die Prozesse mit ps -A angeschaut
> habe, war dort keiner dabei der CPU-Zeit verbrauchte. top zeigt da
> auch 99% idle an, wenn ich das richtig gesehen habe.

Dann würde ich auf zwei wahrscheinliche Ursachen tippen:
- "swap to death" - sprich: wegen RAM-Mangel "swappt er sich zu Tode",
  weil durch die Wartezeit für den Swap die Warteschlange immer länger
  wird
- IO zu lahm - geht in eine ähnliche Richtung

> >> Die delays sehen irgendwie nicht gesund aus, finde ich :(
> > 
> > Mail ist kein instant messaging ;-)
> 
> Schon klar, aber beim googlen habe ich immer delay von <10 gesehen.

Jepp, das ist der Idealfall. 
Deine Delay-Werte sind jedenfalls jenseits von gut und böse ;-)

> > postconf -n [...]

> default_process_limit = 5

> mailbox_command = procmail -a "$EXTENSION"

Nur zur Sicherheit: Hast Du irgendwas "lahmes" in der procmailrc?

BTW: Gehen Deine 1000 Mails eher an lokale Nutzer (via procmail) oder 
eher an externe Mailserver?

> smtpd_client_message_rate_limit = 10

> Auch hier sieht man wieder meinen Versuch, die eingehenden
> Nachrichten etwas zu drossseln: smtpd_client_message_rate_limit = 10

Das bezieht sich auf anvil_rate_time_unit (Default 60 Sekunden), also 10 
eingehende Mails pro Minute und pro smtpd-Prozess

Ich habe stattdessen übrigens
    smtpd_client_connection_count_limit
im Einsatz, weil mir mal jemand alle smtpd-Prozesse auf einmal 
dichtgemacht hat (und ihm dann zu allem Überfluss auch noch die Puste 
ausging und er nicht mehr zum Versand kam). Seit ich die Verbindungen 
pro Client begrenzt habe, bekommt er seine Mails problemlos raus ;-)

> > - komplette master.cf

Da fällt mir auf Anhieb nichts auf, das die Probleme erklären würde.

> > - vollständiger Logauszug (ggf. anonymisiert)
> 
> Welches Log hättest du denn gerne? syslog?

Wir reden hier über Mailprobleme, von daher... ;-)
Ideal wäre das Log für eine Mail vom Connect bis zur Auslieferung.

> hier mal mail.info direkt
> nach einem Neustart bevor ich den Dienst wieder beendet habe, weil
> die Kiste sonst nicht mehr erreichbar war:

Das klingt nach einer gut gefüllten Mail-Warteschlange (siehe Ausgabe 
von "mailq").

In diesem Fall solltest Du den ausgehenden Versand der Mails limitieren. 
Ich bin mir nicht ganz sicher, welcher Parameter das macht, tippe aber 
auf smtp_destination_concurrency_limit ("smtp", nicht "smtp*d*"!).
Allerdings greift das nur pro Zielserver. Eine Option, um die smtp-
Prozesse insgesamt zu begrenzen, habe ich auf Anhieb nicht gesehen.

Siehe dazu auch http://www.postfix.org/TUNING_README.html#mailing_tips

Um die aktuelle Warteschlange geordnet abzuarbeiten, könntest Du die 
Mails manuell auf HOLD setzen (mit postsuper -h ALL) und nach und nach 
wieder freigeben. Ungetestet:

mailq |grep '^[0-9A-F]' | while read id foo ; do
    postsuper -r $id
    sleep 2
done

> Apr 15 15:43:25 apeliotes postfix/master[3417]: daemon started --
> version 2.5.5, configuration /etc/postfix
> Apr 15 15:43:30 apeliotes postfix/pickup[3429]: 4F57A7F40FF: uid=106
> from=<otrs> Apr 15 15:43:30 apeliotes postfix/cleanup[3432]:
> 4F57A7F40FF: message-id=<20110415134330.4F57A7F40FF at ....>

Da kommt also eine neue Mail rein (via lokalem Benutzer). Kannst Du die 
(oder irgendeine andere Mail) mal anhand der Queue-ID (hier: 
4F57A7F40FF) durchs Log verfolgen? Das grep-Ergebnis dann bitte in die 
nächste Mail packen.

Der Rest des Logs zeigt die (verzögert) erfolgreiche Zustellung von ein 
paar Mails an externe Adressen. Da kann ich zumindest kein Problem 
herauslesen, allerdings habe ich die erste Hälfte des Logs (wie/wann die 
Mails reingekommen sind) für diese Mails nicht gesehen.

> Wie gesagt, kleine Mengen machten bisher kein Problem, erst der
> Newsletter hat das System in die Knie gezwungen.

Klar. Bei 10 Mails in der Stunde kann nichts explodieren ;-)


Gruß

Christian Boltz
-- 
> Kann ich auf einen Bootloader (lilo oder grub) verzichten,
> falls auf der Festplatte nur 2 Partitionen sind
Klar kannst du. Vorausgesetzt du kannst auch darauf verzichten
das Betriebssystem zu booten.
[> Wolfgang Erlenkötter und Hartmut Meyer in suse-linux]