Listen queue overflow durch OpenDKIM

S

SolarCatcher

Well-Known Member
Ich sehe auf meinen Servern ab und zu die Listen queue overflows, aber eher selten.

Seit ich kürzlich OpenDKIM zu meinem Postfix eingerichtet habe (nach diesem Howto Configure OpenDKIM with Postfix on FreeBSD), fliegen mir die aber bei der Versendung von Newslettern an tausende von Adressaten regelmäßig um die Ohren.

Auf einem FreeBSD 13 sieht das dann so aus:
Code: 
sonewconn: pcb 0xfffff8152a090800 (local:public/pickup): Listen queue overflow: 151 already in queue awaiting acceptance (1257 occurrences)

Auf einem HardenedBSD 12.3 so:
Code: 
sonewconn: pcb 0xfffff800370ee600: Listen queue overflow: 151 already in queue awaiting acceptance (2293 occurrences)

Ist das normal/erwartbar? Was wäre die sinnvollste Lösung - Rate Limiting des Versende-Skripts? kern.ipc.soacceptqueue hochsetzen? Was ganz anderes?
 
Mal was grundlegendes: Listenqueue größer machen bedeutet ja nur, dass du eine Warteschlange vergrößerst. Wenn die nicht abgebaut wird bringt dir das nichts. Also aus Faustregel. Wenn das ständig passiert lass die Listen Queue wie sie ist. Wenn du Bursts hast/erwartest, dann kann das Hochsetzen Sinn machen.

Nachdem Newsletter nach Bursts klingt könntest du das andenken, allerdings wäre das Rate Limiting wohl die bessere Methode, weil damit auch andere Dinge nicht ins Straucheln geraten und du ja generell den Overflow so gut wie möglich vermeiden willst, vor allem wenn noch andere Dinge als Newsletter passieren. Natürlich kannst du auch beides machen.

Hast du irgendein Delay im Newsletter-Skript? Wenn nein würde ich jedenfalls mal eines einbauen, auch wenn du es sehr niedrig setzt. Wäre auch spannend zu erfahren von welcher Größenordnung wir da sprechen. Kannst du da mal schauen, wie lange das Skript läuft und wie viele Mails das sind und uns dann sagen wie viele das pro Sekunde ausmacht? Dann kann man runterbrechen wie groß das Delay sein sollte. Oder eben einfach mal eines einbauen, wenn keines ist kannst du ja mal mit 100ms beginnen und dich entsprechend runter arbeiten.

Sind halt doch digitale Signaturen, die etwas Prozessorzeit. Ich weiß leider nicht ob man bei OpenDKIM schrauben kann oder wie sich Alternativen im Vergleich von der Performance her verhalten, deshalb würde ich da ehrlich gesagt einfach mit dem Rate-Limit rangehen, als wahrscheinlich simpelste sinnvolle Lösung und dann entscheiden ob wie lang das Skript dann läuft für den Einsatzzweck vertretbar ist.
 
Danke für Deine Überlegungen/Tipps.

Ich habe gerade mal nachgeschaut und gerechnet: Gestern waren es auf dem einen Server gut 4.500 Mails in ca. 400s, also rund 11-12 Mails/Sekunde.

Dein Vorschlag mit einer kleinen Verzögerung von 100ms reinzugehen, scheint mir logisch. Das probiere ich mal aus und erhöhe den ggf. bis die Overflows (nahezu) verschwunden sind.
 
Bin gespannt was das Ergebnis ist. Wenn der Server noch andere Mails aussendet bzw. für andere Dinge genutzt wird und der Newsletter nicht allzu zeitkritisch ist (sind Newsletter ja eher nicht) würde ich noch empfehlen eher hoch anzusetzen mit dem Delay. Dann verhinderst du, dass mal vielleicht was anderes auch noch reinkommt oder der Server durch irgendwas mehr Last hat und es so zu Problem kommt.

Also man will ja eher verhindern, dass Newsletter im Fall des Falles von Menschen gesendete oder auch automatisierte individuelle Mails (Passwort vergessen, etc.) "blockieren".
 
Sieht gut aus: Die gut 4.500 Mails sind diesmal ohne listen queue overflow rausgegangen. Die Skript-Dauer hat sich von ca. 400 auf ca. 600s erhöht, die versendeten Mails pro Sekunde von gut 11 auf knapp 8 reduziert. Offenbar langte das schon.

Dann werde ich das auf dem anderen Server auch mal so einstellen.

Nochmal ganz herzlichen Dank für den Tip.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben