Langsame SMTP-Verbindungen zur Speicherüberlastung von Google (Steuern von Exim-Timeouts)

429
steev

Unsere Organisation verfügt über mehrere Server, die viele E-Mails generieren und versenden (wir sind keine Spammer, es handelt sich um echte E-Mails an Benutzer, die danach gefragt haben). Exim auf diesen Computern ist so konfiguriert, dass nur einmal versucht wird, E-Mails zuzustellen. Wenn dies fehlschlägt, übergeben Sie die E-Mail an einen Überlauf-Hub-Server, der es weiterhin versucht. Ich habe gerade einen neuen Server zu dieser Herde hinzugefügt und ihn zu unserem SPF-Datensatz hinzugefügt und genau wie unsere anderen Server konfiguriert. Wir müssen uns jedoch auf einer schwarzen Liste oder eher mit einer grauen Liste bei Google befinden. Dies liegt wahrscheinlich daran, dass der Netblock dieses neuen Servers einen schlechten Ruf hat, da E-Mails an Google Mail-Konten beim ersten Versuch immer mit einem Verbindungsfehler abbrechen. Ich habe von Hand versucht, an Google Mail-Adressen zu senden, und wenn mehrere Versuche unternommen werden dürfen, funktioniert dies einwandfrei. Ich kann sehen, dass der erste Versuch fehlschlägt und der zweite Versuch funktioniert. Kein Problem. Aber wie gesagt,

Das Problem ist, dass ich mit einer Reihe von Exim-Prozessen ende, die darauf warten, dass Google die Verbindung unterbricht. Ich denke, dies führt dazu, dass der Speicherplatz auf der Maschine maximal ausgereizt wird (es handelt sich um eine virtuelle Maschine, also nur 512 MB RAM) und dann Der OOM_killer des Kernels beginnt, Prozesse zu beenden, und wir verlieren E-Mails, die ausgehen sollen.

Ich gehe nicht davon aus, dass Google in Kürze von Greylist aufgegeben wird. Die wirkliche Lösung, die ich sehen kann, besteht darin, herauszufinden, wie man die Exim-Prozesse schneller aufgibt, so dass mir der Speicher nicht ausgeht. Gibt es eine Möglichkeit in der Exim-Konfiguration, dies zu tun? Oder einfach begrenzen, wie viele Exim-Prozesse insgesamt auf dem System ausgeführt werden? Beachten Sie, dass dies separate Exim-Prozeduren sind, die von unserer benutzerdefinierten E-Mail-Generierungssoftware abgefeuert werden. Sie sind keine Kinder des Haupt-Exim-MTA. Ich sehe in den Exim-Dokumenten nichts, was sich anscheinend auf eines dieser Dokumente beziehen würde.

Hinweis: Ich habe bereits versucht, mit hubbed_hosts Exim nicht einmal für Google-Ziele zu versuchen, aber das funktioniert nicht. Vielleicht habe ich die Formatierung meiner hubbed_hosts-Datei falsch? Dies ist es (mit Domainname verschleiert):

.*google.com: bulkflow.mydomain.org .*gmail.com: bulkflow.mydomain.org 

Wenn ich das falsch habe und es reparieren kann, ist das vielleicht die Antwort.

0

1 Antwort auf die Frage

0
wurtel

Entfernen Sie die .*Datei aus Ihrer hubbed_hosts-Datei, einfach gmail.comusw. ist korrekt.

Überprüft darüber hinaus die hervorragende Dokumentation und suchen Sie nach Artikeln wie queue_run_max, queue_load_max, queue_onlyund smtp_receive_timeout.

Beachten Sie, dass exim sehr gut im Umgang mit Nachrichten ist. Selbst wenn ein Prozess, der eine Nachricht verarbeitet, beendet wird, bleibt die Nachricht in der Warteschlange. Der Verlust von Nachrichten sollte daher kein Problem sein.

Ich habe exim verwendet, um hunderte von Tausenden von E-Mails pro Tag zuzustellen, und exim bietet viele Tuning-Parameter, damit alles reibungslos funktioniert.

Danke für die Infos zu hubbed_hosts! Zur Klarstellung meinte ich, dass unsere Software, die die E-Mails generiert, abgetötet wird. Wir verlieren also alle E-Mails, an deren Erstellung noch gearbeitet wird. steev vor 9 Jahren 0
Ich habe jetzt die hubbed_hosts-Einträge geändert, aber ich sehe immer noch die Anzahl der exim-procs, der Speicher wird knapp und unser Email-Generator wird vom Kernel getötet. Ich sehe in exim docs nirgendwo eine Möglichkeit, die Gesamtzahl der auf dem System ausgeführten Exim-Prozesse zu begrenzen. Ich denke, das einzige, was wir tun müssen, ist, unseren Code so zu ändern, dass nicht zu viele Exim-Prozesse gleichzeitig ausgelöst werden. steev vor 9 Jahren 0
Haben Sie nicht gesehen, dass ich die Parameter 'queue_ *' erwähnte? wurtel vor 9 Jahren 0
Ich habe es tatsächlich getan. Wir verwenden bereits queue_run_max und queue_load_max und ich möchte nicht alles ** in eine Warteschlange stellen. steev vor 9 Jahren 0