[Postfixbuch-users] queue File write error

[Sandy Drobic]

Peer Heinlein wrote:
> Am Freitag, 22. Februar 2008 schrieb Sandy Drobic:

>> Nächste Woche habe ich etwas Zeit, dann werde ich das mal in der Praxis
>> testen.
> 
> Ich implementiere das jede Woche so.

Ich meine damit den Maildurchfluss, wenn der Server wirklich zur Sättigung 
kommt. Solange es nicht zu Timeouts beim sendenden Client kommt, wird es mit 
Proxy genausoschnell gehen wie mit content_filter.

>>> ...und die mehr als 5-7 gleichzeitig laufenden smtpds drücken die
>>> Mails dann auf ganz zauberhafte Art und Weise plötzlich doch ganz
>>> flott durch den Amavis, nur weil der post-queue läuft?! Nein.
>> Die mehr als 5-7 gleichzeitigen Mails bringen den Server mit 512 MB RAM
>> in die Gefahr, die Grätsche zu machen, danach ist der Mailfluss nicht
>> mehr so toll. (^-^)
> 
> Mißverständnis.
> 
> Ich hatte mich ja nur gegen die Behauptung gewehrt, daß es dann 
> schneller/besser gehen würde.

Besser im Sinne der Wahrung der Policy, was anzunehmen/abzulehnen ist, ist auf 
jeden Fall smtpd_proxy_filter, da gibt es keinen Zweifel.

>> Wenn ich mich recht erinnere, ist die Empfehlung für die RAM-Disk etwa
>> 2 x message_size_limit x Anzahl-Amavisd-new-Prozesse.
> 
> Es ist *EINE* Empfehlung.
> 
> Ich empfehle etwas anderes. 
> 
> Die Erfahrung zeigt, daß man mit 180 MByte RAM-Disk bei 25 simultan 
> filternen Amavis-Prozessen im Alltag hervorragend arbeiten kann.  
> Zumindest die letzten 500 Millonen Mails waren kein Problem. Wir rollen 
> des jede Woche bei irgendeinem Kunden aus und da geht's auch wirklich um 
> relevante Größenordnungen.

Heute morgen hatte ich eine Mitarbeiterin, die mal an ein paar dutzend Leute 
eine 70MB-Mail geschickt hat (nicht privat). Wenn ich mir jetzt vorstelle, das 
auf 180 MB RAM-Disk zu durchwühlen... (^-^)

>> Bei einer erlaubten message_size_limit von 20 MB kommt das auf:
>> 2 x 20MB * 15 = 600 MB. 
> 
> Überzogen und unnötig.
> 
>> 424 MB, nicht gerade die Welt. Vielleicht kann man argumentieren, dass
>> es unwahrscheinlich ist, auf einmal soviele große Mails zu bekommen,
> 
> Wahrscheinlichkeit ist nur eine Sache, das andere ist, daß das schon durch 
> die technische Kapazität des Servers geregelt wird, der nicht wirklich 
> alle Mails dieser Größe *wirklich* zeitgleich bearbeitet. Das schafft er 
> ja nicht.

Wenn halt eine Serie dieser dicken Mails kommt (und ich hatte die auf unserem 
Server leider), dann kommt es aber genau zu der Situation.
Die Zeit, die die Mails durch Amavisd-new brauchen, geht dann drastisch in die 
Länge. :-/


>> Lieber auf 2 
>> GB aufrüsten, dann stimme ich dir zu. Aber selbst dann bekommst du mit
>> einer CPU und 15 Prozessen eine längliche Abwicklung in Amavisd-new.
> 
> Meine Erfahrung zeigt etwas anderes, ich halte 15 hier für einen optimalen 
> Wert.

Bei welcher CPU? Bei einem P3 halte ich das nicht für angemessen.

> Die Messungen von Mark Martinec sagen übrigens auch was anderes.

Ich muss mir die Messungen noch einmal ansehen, auf was für Hardware sie 
gelaufen sind. Mark hatte aber mehrfach betont, dass Amavisd-new nicht als 
proxy_filter vorgesehen ist, obwohl er wohl mitbekommen hat, dass inzwischen 
immer mehr Amavisd-new so einsetzen. ;-)


-- 
Sandy

Antworten bitte nur in die Mailingliste!
PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com