[Postfixbuch-users] nochmal no-reverse-DNS-reject

[Sandy Drobic]

Thomas Klein wrote:


> naja, es ist ehrlich gesagt nur eine IDE-Platte mit 40 GB drin. Die 
> Kiste ist so gesehen dringend ersetzungswürdig (meiner Meinung), da wird 
> auf jeden Fall demnächst was passieren. Wieviel RAM ist denn für ein 
> solches Mailaufkommen anzuraten? Ich bin auch mal davon ausgegangen, das 
> gute SATA-Platten ausreichend sein sollten. Die Mails werden weiter an 
> einen Exchangeserver gerouted.

Das ist eine Abschätzung, in der auch eingeht, wie schnell die Mails
abgearbeitet werden sollen und welche Schübe von Mail erwartet werden.
Wenn zu bestimmten Zeiten plötzlich ein paar tausend Mails innerhalb
weniger Minuten reinströmen und dann auch noch zeitnah weitergeleitet
werden sollen, ist das etwas anderes, als wenn man sich die Zeit nehmen
kann, eine Queue abarbeiten zu lassen bei solchen Schüben.

Auf einem Gateway hast du normalerweise folgende Schwerpunkte:

Postfix: 	schnelle Platten für viel I/O
Amavis/SA: 	viel RAM und CPU, dazu noch für Tempdateien schneller
		Plattenplatz

Insgesamt brauchst du somit einen Rechner der auf jeden Fall flinke
Platten hat und genügend CPU-Leistung, um Amavis anzuschieben.

Das RAM begrenzt dabei die Zahl der möglichen gleichzeitigen Prozesse.

Wenn ich heute einen neuen Relayserver kaufen muss, dann wird es ein
Rechner mit Dualcore CPU, 2 GB RAM aufwärts und Platten, die an einem
RAID-Controller hängen, der ordentlich Cache hat.

Wenn hoher Durchzatz erwartet wird, den Raid-Controller auch gerne mit BBU
und 1 GB Cache.

Reicht auch das nicht, spendiert man dem Server eine Solid-State-Disk für
den Temp-Speicher.


Was bei dir am meisten hilft, wäre etwas mehr RAM. 1 GB ist in Ordnung.
Dazu dann noch eine etwas schnellere Platte und tempfs für die
Temp-Verzeichnisse.

> 
> Habe mal dig name.de gemacht:
> dig name.de
> 
> ; <<>> DiG 9.2.4 <<>> name.de
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24581
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
> 
> ;; QUESTION SECTION:
> ;name.de.                       IN      A
> 
> ;; ANSWER SECTION:
> name.de.                86400   IN      A       213.160.68.3
> 
> ;; AUTHORITY SECTION:
> name.de.                86400   IN      NS      ns8.routing.net.
> name.de.                86400   IN      NS      ns.routing.net.
> 
> ;; ADDITIONAL SECTION:
> ns.routing.net.         112289  IN      A       213.160.64.64
> ns8.routing.net.        112289  IN      A       213.160.65.64
> 
> ;; Query time: 2704 msec
> ;; SERVER: 213.138.34.20#53(213.138.34.20)
> ;; WHEN: Thu Jun 14 11:59:37 2007
> ;; MSG SIZE  rcvd: 119
> 
> 
> 2704 msec ist sicher nicht glorreich, wäre wohl eine Erklärung für mein 
> Problem, oder?

Das ist mehr als grausam. (^-^)

 dig name.de

; <<>> DiG 9.3.2 <<>> name.de

;; Query time: 59 msec
;; SERVER: 192.168.0.50#53(192.168.0.50)
;; WHEN: Thu Jun 14 13:10:54 2007
;; MSG SIZE  rcvd: 119

Und hier beim zweiten Aufruf:

 # dig name.de

; <<>> DiG 9.3.2 <<>> name.de

;; Query time: 2 msec
;; SERVER: 192.168.0.50#53(192.168.0.50)
;; WHEN: Thu Jun 14 13:21:51 2007
;; MSG SIZE  rcvd: 119

Cachen ist etwas wunderbares.


> Scheint auch nur sporadisch zu sein, bei anderen Domains gehts schneller 
> (50ms, 34 ms).
> Vielleicht sollte ich mal einen anderen DNS ausprobieren? Der Server hat 
> einen SDSL-Anschluss von Versatel, da kann ich (glaube ich) keine 
> Telekom-DNS Server verwenden. Bitte mal um einen Vorschlag.

Setze einen lokalen Bind auf, das ist in kurzer Zeit gemacht (Konfig kam
vor wenigen Tagen hier) und bringt richtig Beschleunigung bei der Auflösung.


-- 
Sandy

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