Postfix zu langsam

T

topoh

New Member
Hallo Gemeinde,

suche schon seit einigen Nächten eine Lösung für meinen zu langsamen Postfix! Seit ich bei Hetzner bin bekomme ich keine Geschwindigkeit auf den Postfix, E-Maildurchsatz liegt bei 5 Mails innerhalb einer Sec.! Auf dem alten Server waren/sind es ca. 30 Mails innerhalb der gleichen Sec.

Da ich immer mit den gleichen Konfigurationsfiles arbeite und meine anderen 3 Server es ähnlich haben, 30 Mails pro sec., komme ich allmählich nicht mehr weiter! Den einzigen unterschied den ich sehe ist, die anderen 3 Server haben alle eine HDD und nutzen noch nicht die neuen Versionen von Postfix und PHP.

Evtl. hat einer hier eine zündende Idee warum Postfix bei gleichen Konfigurationen einfach soooo lahmt? Wie gesagt das System läuft, Mails können gesendet wie empfangen werden, das funktioniert alles, es geht nur um die Geschwindigkeit!

System läuft mit Postfix/Dovecot in Version Postfix 2.7.1 und PHP 5.3.3-7 auf einem Sueeze 64bit System mit einem Intel I7 2700 8 Kernen und 16 GB Speicher, 2x 3Tbyte Hdd Softraid1.

DNS läuft sauber und wird aus allen Lagen erkannt, ebenso das Reverse DNS ist OK HDD Plattendurchsatz liegt bei ca 170MB /sec.

Und Trotzdem nur 5 Mails innerhalb einer Sec.

Auf dem alten Server Debian Lenny, 2 Kerne, 4GB Speicher und 800GB HDD macht der Postfix ca 30 Mails innerhalb einer sec. kann man schhön im mail.log sehen wie viele Mails innerhalb der gleichen Sec abgearbeitet werden.

Daten des Postfix werden alle aus der Datenbank abgearbeitet über mysql abfragen. Postfix, Dovecot, Mysql, Froxlor, Phpmyadmin, Apache2, Proftpd, nutze ich auf allen Servern als Standart mit immer den gleichen Konfigurationen die aus Froxlor früher SysCP vorgegeben werden.

Hmmm, was wird noch benötigt? Eine Postconf evtl. noch?

Mfg topoh
 
Ich lese aus deinem Post heraus, dass du MySQL als Backend für Postfix benutzt. Vergleiche zusätzlich noch die /etc/mysql/my.cnf auf gleichheit.
 
Oder was sagt ein
Code: 
yes quit | telnet <MAILSERVER> 25
?
 
Bierteufel said:
Noch irgendwelche extra Milter / Filter mit zugeschalten, wo die Mails erst durchgehen ?
Click to expand...

Nein, die nutze ich im Moment gar nicht, und auf den neuen Server habe ich die nicht mal Installiert, so etwas sollte erst kommen wenn ein System auch richtig läuft.
Auf einen der anderen Lenny Server habe ich den Milter drauf für die E-Mails, aber der läuft damit super.
 
PCFreund said:
Ich lese aus deinem Post heraus, dass du MySQL als Backend für Postfix benutzt. Vergleiche zusätzlich noch die /etc/mysql/my.cnf auf gleichheit.
Click to expand...

So, naja der Hinweis brachte schon mal das ich da nicht verglichen habe, danke.
Aber das war es dann auch nicht, nachdem ich die my.cnf angepasst habe ging es auch nicht schneller, schade ich hatte jetzt so gehofft das wäre es.

Postfix verarbeitet weiterhin die Mails nur Plätscherweise.

Mfg topoh
 
Erstmal, wie misst du den "Durchsatz" von Postfix, außer Logfiles lesen :rolleyes:? Evtl. kommen einfach nicht mehr E-Mails rein?

Wie kannst du auf den neuen Server schon E-Mails (von deinen Kunden?) empfangen wenn der "alte" noch in Betrieb ist?
 
Jenstheclown said:
Erstmal, wie misst du den "Durchsatz" von Postfix, außer Logfiles lesen :rolleyes:? Evtl. kommen einfach nicht mehr E-Mails rein?
Click to expand...
Na Mails kommen genug rein (Paid4 Bereich), ein Kunde verschickt 10 Werbemails an 2700 User alle 2 Tage, macht 10x2700 = 27000 Mails. Dafür hat der Kunde bis vor anderthalb Woche auf dem alten Server noch 30min gebraucht, dann waren die durch. Jetzt auf dem neuen Server 2,5 Stunden manchmal 3 Stunden, wenn er sie nach und nach ins System stellt, also erst ein zwei Mails und wenn die dann durch sind die nächsten zwei und so weiter.

Wie kannst du auf den neuen Server schon E-Mails (von deinen Kunden?) empfangen wenn der "alte" noch in Betrieb ist?
Click to expand...

Ich habe den alten noch in Betrieb und dort sind noch 2 Kunden drauf, der Rest ist schon auf den neuen Server, so habe ich einen direkten Vergleich.
Ich habe sogar als Test einmal die gleiche Mail an 390 User auf dem alten Server geschickt und dann das gleiche auf dem neuen Server. Alter Server zwischen 6 und 8 sec fertig, auf dem neues Server dauert dieser Vorgang 45sec bis 390 Mails durch sind, und das ist noch eine kleine Menge, ich kann den Kundne mit 2700 Usern Verstehen wenn er sagt es lahmt alles auf den neuen Server. Und selbst die Kunden die weit weniger User auf Ihren Paidmailern haben (im Schnitt zwischen 400 und 600 User) merken deutlich das es langsamer geht! Leider kann ich nicht mehr zurück, der alte Server ist schon gekündigt :-(

Nachtrag:
Hmm, da fällt mir noch ein, ich habe gestern noch diesen Test in dem Link:
http://postfixmail.com/blog/index.php/postfix-stress-test-with-smtp-source-and-top/
so durchgeführt mit insgesamt 5000 Mails, und den Beschriebenen wa Wert um den es dort geht liegt bei 17,5%wa am höchsten. Alle anderen Snapshots lagen darunter. Ich denke es geht bei dem Test um die I/O Performance der Festplatte, also lese / schreibzyclen. Irgendwo oben steht auch was von 10% sollten wohl nicht überschritten werden, weil sich das mit höherem wa Wert immer weiter steigert, ähmm ja, mein English ist nicht sonderlich gut.....Jedenfalls habe ich das so in etwa verstanden. Die Testdatei habe ich noch auf dem Server liegen von den Snapshots.
 
Last edited by a moderator:
Um keine Mails bei einem Crash zu verlieren, müssen diese immer vom Filesystem Cache auf die Platte geschrieben sein, bevor dem Versender die Annahme quittiert wird. Ich würde deshalb in Richtung I/O weitersuchen:

  • ist auf dem neuen Server ein anderes Filesystem (EXT3/EXT4/XFS/...)?
  • sind die Mount-Optionen identisch?
  • ist auf dem neuen Host vielleicht der Cache auf der Plate deaktiviert?

Eventuell mal den Output von
Code: 
iostat -kx 1 5
vergleichen/posten.
 
Cenic said:
Eventuell mal den Output von
Code: 
iostat -kx 1 5
vergleichen/posten.
Click to expand...

Hier erst mal die von Munin zur Verfügung gestellten IO Daten von Platte 1 und 2:
http://topoh.de/sda-day.png
http://topoh.de/sdb-day.png

Ob das gute oder schlechte Werte sind kann ich nicht beurteilen, und hier noch das iostat Ergebniss:

avg-cpu: %user %nice %system %iowait %steal %idle
1.43 0.03 0.65 1.89 0.00 96.00

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sdb 1.68 60.32 0.27 14.05 14.03 293.22 42.89 0.42 29.26 8.19 11.73
sda 0.54 60.32 0.23 14.05 8.79 293.22 42.31 0.43 30.41 8.50 12.13
md0 0.00 0.00 0.00 0.00 0.00 0.00 7.82 0.00 0.00 0.00 0.00
md1 0.00 0.00 0.00 0.00 0.00 0.00 7.87 0.00 0.00 0.00 0.00
md2 0.00 0.00 0.51 73.53 13.96 292.37 8.28 0.00 0.00 0.00 0.00
md3 0.00 0.00 0.00 0.00 0.00 0.00 5.78 0.00 0.00 0.00 0.00

avg-cpu: %user %nice %system %iowait %steal %idle
0.26 0.00 0.52 15.18 0.00 84.05

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sdb 0.00 121.00 0.00 50.00 0.00 676.00 27.04 2.97 59.36 8.32 41.60
sda 0.00 123.00 0.00 48.00 0.00 680.00 28.33 3.72 76.08 20.58 98.80
md0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
md1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
md2 0.00 0.00 0.00 171.00 0.00 676.00 7.91 0.00 0.00 0.00 0.00
md3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

avg-cpu: %user %nice %system %iowait %steal %idle
0.24 0.00 0.49 19.41 0.00 79.85

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sdb 0.00 111.00 0.00 20.00 0.00 524.00 52.40 0.86 35.80 22.40 44.80
sda 0.00 111.00 0.00 22.00 0.00 528.00 48.00 1.96 93.45 45.45 100.00
md0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
md1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
md2 0.00 0.00 0.00 133.00 0.00 532.00 8.00 0.00 0.00 0.00 0.00
md3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

avg-cpu: %user %nice %system %iowait %steal %idle
1.34 0.00 0.98 17.44 0.00 80.24

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sdb 0.00 126.00 0.00 31.00 0.00 628.00 40.52 0.84 31.61 13.81 42.80
sda 0.00 127.00 0.00 28.00 0.00 620.00 44.29 1.92 67.00 35.43 99.20
md0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
md1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
md2 0.00 0.00 0.00 155.00 0.00 620.00 8.00 0.00 0.00 0.00 0.00
md3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

avg-cpu: %user %nice %system %iowait %steal %idle
0.89 0.00 0.89 16.37 0.00 81.85

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sdb 0.00 126.00 0.00 25.00 0.00 604.00 48.32 0.90 35.84 18.40 46.00
sda 0.00 128.00 0.00 23.00 0.00 604.00 52.52 1.94 83.83 43.30 99.60
md0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
md1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
md2 0.00 0.00 0.00 151.00 0.00 604.00 8.00 0.00 0.00 0.00 0.00
md3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

Plattengröße: sind zwei 3TB Platten Type GPT.

Mfg topoh
 
Erstmal: es wäre lesbarer gewesen, wenn du den Output in passende Tags gesteckt hättest...

Die 5 Messwerte sehen sich echt ähnlich, deshalb der Einfachheit halber hier die Anmerkungen zum letzten Block. CPU ist kein Problem 81.85% idle.

Für die Platten nehme ich mal nur die letzten Spalten. Die letzte Spalte %util ist die prozentuale Auslastung, d.h. das Verhältnis von aktiver Zeit zur Gesamtzeit. Die 99.6% für sda stimmen da schonmal nachdenklich.

Vorletzte Spalte: svctm ist die Service-Zeit, d.h. die Zeit, die ein einzelner I/O im Schnitt braucht, um von der Platte verarbeitet zu werden. Die 18.4ms für sdb und 43.3ms für sda sind ziemlich übel. Moderne Platten sollten unter 10ms liegen. Gerade mal nachgeschaut: die IBM 3350 (das ist eine 317MB Platten von 1975) kommt auf etwa 33ms.

Neben der eigentlichen Service-Zeit für einen I/O kommt noch eine Wartezeit dazu, wenn die Platte gerade schon einen anderen I/O verarbeitet. Die Länge der Warteschlange (Spalte avgqu-sz) ist mit 1-2 Stück nicht so dramatisch, aber durch die lange Service-Zeit für einen I/O kommt diese Zeit natürlich als Wartezeit für den Rest der Schlange dazu. In Summe dauert es (Spalte await) für sdb 35.84ms und für sda 83.83ms, bis ein von einer Applikation abgesetzter I/O dann von der Platte wirklich verarbeitet wurde.

Weil für jeden I/O des Mailers aber zur Sicherheit immer gewartet wird, bis der sicher auf der Platte ist, hast du hier m.E. den Engpass. Eine moderne Platte müsste 10x schneller arbeiten.

Da sehe ich ein Problem mit der Hardware. Vielleicht spielt das Thema 4K Sektorgröße auch eine Rolle.
 
Cenic said:
Vielleicht spielt das Thema 4K Sektorgröße auch eine Rolle.
Click to expand...
Darauf würde ich wetten:
Code: 
update-smart-drivedb
smartctl -i /dev/sda
smartctl -i /dev/sdb
parted /dev/sda print
parted /dev/sdb print
 
Last edited by a moderator:
So hier noch mal ein DD Test:

Code: 
xxx@xxx: ~# dd if=/dev/zero of=/file bs=1MB count=500

xxx@xxx: ~# 500000000 bytes (500 MB) copied, 0.311293 s, 1.6 GB/s

Ich denke die Platte(n) sind schnell genug? Hoffe ich doch.
Langsam geht mir echt die Puste aus....sitze schon wieder seit 8 Std. am Rechner und mache Ferntestungen :(

Mfg. topoh
 
Dein Test berücksichtigt m.E. zwei Dinge nicht:

Die Blockgröße von 1MB ist viel zu groß und wenig große Bereiche auf Platte schreiben geht immer schneller als viele kleine. Auf Basis der Ausgabe von iostat sehe ich 32k als realistischer an.

Viel entscheidender ist jedoch, dass du in den Filesystem Puffer schreibst und je nach RAM-Ausbau am Ende des Tests noch kein Byte wirklich auf der Platte angekommen ist. Wie erwähnt sorgt ein Mailer jedoch dafür, dass wirklich alles auf die Platte gekommen ist, bevor der dem Client die Mail quittiert. Bei dd kannst du das durch die zusätzliche Option oflag=sync nachstellen.

Ich halte das hier für einen besseren Test:
Code: 
# dd if=/dev/zero of=/file bs=32k count=50000 oflag=sync
 
Cenic said:
Dein Test berücksichtigt m.E. zwei Dinge nicht:
Click to expand...

Jep da könntest du Recht haben, ich habe das mal mit dem alten Server verglichen, hier sind die Werte:

Alter Server: :D
Code: 
thopoh3:~# dd if=/dev/zero of=/file bs=32k count=50000 oflag=sync
50000+0 Datensätze ein
50000+0 Datensätze aus
1638400000 Bytes (1,6 GB) kopiert, 67,6889 s, 24,2 MB/s

Neuer Server:
Den habe ich nach ca. 45 min abgebrochen, weil ich vermutlich keine 2 Std. warten wollte, aber das zeigt das hier die Hardware nicht stimmt und mit den Platten etwas nicht in Ordnung sein muss.

Ich habe den Test dann mal auf nur 5000 begrenzt um ein Ergebnis zu erhalten.

Alter Server: :D
Code: 
thopoh3:~# dd if=/dev/zero of=/file bs=32k count=5000 oflag=sync
5000+0 Datensätze ein
5000+0 Datensätze aus
163840000 Bytes (164 MB) kopiert, 6,8163 s, 24,0 MB/s

Neuer Server: :mad:
Code: 
root@1atpr63 ~ # dd if=/dev/zero of=/file bs=32k count=5000 oflag=sync
5000+0 records in
5000+0 records out
163840000 bytes (164 MB) copied, 439.239 s, 373 kB/s

wie man sieht braucht der Neue Server rund 7,5 min während der Alte schon nach 6,8sec fertig ist.
Tja, was mach ich jetzt? Darum bitten das die mir eine vernünftige HDD einbauen oder kann man das irgendwie beheben ohne alles neu Installieren zu müssen (Produktives System).

Das ist übrigends das Platten Modell : Seagate ST3000DM001-9YN1 7200 U/min 6Gbit's angeblich.

Mfg topoh

Edit Nachtrag:
Aus Webmin Information: CPU Auslastung 4% Benutzer, 1% Kernel, 12% IO, 83% Leerlauf

Der IO ist also sehr hoch wenn Mails gesendet werden, ist auf dem alten System nicht so der Fall.
 
Last edited by a moderator:
Liefer bitte mal die Infos aus meinem vorigen Post und zusätzlich Infos zum Filesystem (Typ, Version, Optionen), danke.
 
Joe User said:
Liefer bitte mal die Infos aus meinem vorigen Post und zusätzlich Infos zum Filesystem (Typ, Version, Optionen), danke.
Click to expand...

Hier die beiden HDDs mit Parted:
Code: 
Model: ATA ST3000DM001-9YN1 (scsi)
Disk /dev/sda: 3001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start   End     Size    File system  Name  Flags
 5      1049kB  2097kB  1049kB                     bios_grub
 1      2097kB  34.4GB  34.4GB                     raid
 2      34.4GB  34.9GB  537MB                      raid
 3      34.9GB  1134GB  1100GB                     raid
 4      1134GB  3001GB  1866GB                     raid


Model: ATA ST3000DM001-9YN1 (scsi)
Disk /dev/sdb: 3001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start   End     Size    File system  Name  Flags
 5      1049kB  2097kB  1049kB                     bios_grub
 1      2097kB  34.4GB  34.4GB                     raid
 2      34.4GB  34.9GB  537MB                      raid
 3      34.9GB  1134GB  1100GB                     raid
 4      1134GB  3001GB  1866GB                     raid

und hier beide mit smartctl:
Code: 
smartctl -i /dev/sda
smartctl 5.40 2010-07-12 r3124 [x86_64-unknown-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF INFORMATION SECTION ===
Device Model:     ST3000DM001-9YN166
Serial Number:    S1F0L9NT
Firmware Version: CC4B
User Capacity:    3,000,592,982,016 bytes
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   8
ATA Standard is:  ATA-8-ACS revision 4
Local Time is:    Sat Jul 21 18:12:43 2012 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled


smartctl -i /dev/sdb
smartctl 5.40 2010-07-12 r3124 [x86_64-unknown-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF INFORMATION SECTION ===
Device Model:     ST3000DM001-9YN166
Serial Number:    W1F0LN74
Firmware Version: CC4B
User Capacity:    3,000,592,982,016 bytes
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   8
ATA Standard is:  ATA-8-ACS revision 4
Local Time is:    Sat Jul 21 18:13:51 2012 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

der erste Befehl funktioniert nicht mit update.

Mfg topoh
 
Moin,


Ich habe schon mehrmals gelesen das es bei einigen Servern probleme gibt. Bei dem Hoster scheinen einige Platten einen weg zu haben und müssen getauscht werden .

Wenn hier keine Lösung gefunden werden sollte wende dich mal an den Hoster und Frage ob die dir die Platten tauschen.
 
Der TE hat aber nach wie vor noch keine Dinge wie Dateisystem und Mount-Optionen genannt. Wer weiß...
 
You must log in or register to reply here.
Back
Top