PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Postfix Server optimieren, hoher iowait



chris_h
06.06.08, 10:34
Hi,

habe einen Postfix (Greylisting, Nod32 AV, ClamAV als Backup) der nicht mehr ganz neue Hardware hat. Bevor neue Teile installiert werden, würde ich gerne etwas an der Optimierung arbeiten.

Das Problem: ca. 90% der Zeit ist die CPU in iowait


top - 10:09:04 up 1 day, 17:44, 1 user, load average: 4.34, 4.26, 3.51
Tasks: 160 total, 2 running, 158 sleeping, 0 stopped, 0 zombie
Cpu(s): 2.7%us, 1.0%sy, 0.0%ni, 0.0%id, 96.3%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 906792k total, 887056k used, 19736k free, 118324k buffers
Swap: 192772k total, 40k used, 192732k free, 448140k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3959 postgrey 18 0 11096 8852 2824 D 1.3 1.0 10:50.92 postgrey
14949 amavis 15 0 52680 45m 2600 S 0.7 5.1 0:01.11 amavisd-new
3930 root 15 0 4772 3360 628 S 0.3 0.4 3:28.48 syslog-ng
3943 root 15 0 29168 26m 756 S 0.3 3.0 7:38.52 named
13177 postfix 15 0 5348 2516 2032 S 0.3 0.3 0:00.06 smtpd
13178 postfix 15 0 5348 2516 2036 S 0.3 0.3 0:00.06 smtpd
14966 chris 15 0 2360 1184 856 R 0.3 0.1 0:00.03 top
1 root 15 0 1944 636 544 S 0.0 0.1 0:01.29 init
2 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0
3 root 10 -5 0 0 0 S 0.0 0.0 0:00.02 events/0
4 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 khelper
5 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kthread
8 root 10 -5 0 0 0 S 0.0 0.0 0:00.21 kblockd/0


Ich habe sync bei syslog schon auf 50 gesetzt, damit die Festplatte nicht immer beansprucht wird.
/var/lib/amavis/tmp ist auf ein tmpfs ausgelagert.

Ideen?
Tkx,
Chris

Wene
08.06.08, 15:57
Ohne mehr über die Hardware zu wissen wird das hier eine fröhliche Raterunde.

Vor allem interessieren mich an deiser Stelle die Blockdevices, aber auch alles andere könnte eine Information wert sein.

chris_h
09.06.08, 10:48
Um das Raten abzukürzen:
RAM: 1GB
Motherboard: VIA EPIA SN-Series Mini-ITX
CPU C7: 1.8Ghz
Blockdev.: CF Karte, 16GB Transcent, 133x

Habe die Anzahl der gleichzeitigen smtp Prozesse auf 50 beschränkt. Alle Cron-Einträge sind auf mehrere Nachstunden verteilt.

marce
09.06.08, 10:55
Blockdev.: CF Karte, 16GB Transcent, 133x
damit mMn. nicht verwunderlich.

bla!zilla
09.06.08, 11:04
Jap, würde ich auch so sehen. IOwait ist immer ein sicheres Anzeichen für ein zu langsames Blockdevice. Versuch mal Postgrey DB und Spoolverzeichnis in ein tmpfs zu legen.

marce
09.06.08, 11:11
Features:
[...]
- Data transfer rate: 21.5MB/sec(Max)
[..]
"schnell" ist also was anderes...

bla!zilla
09.06.08, 11:24
Da steht ja auch max. Was aber nicht aussagt, wie groß die I/Os waren. Immer schön vor Augen halten: MB/s = IOPS * Transfer Size.

chris_h
09.06.08, 13:55
Ja, die PostgreyDB, das wäre noch eine Möglichkeit. Muss mal mehr RAM investieren.

bla!zilla
09.06.08, 14:44
Wie groß ist die DB jetzt?

chris_h
12.06.08, 09:04
du -s /var/lib/postgrey/
44940 /var/lib/postgrey/

chris_h
24.06.08, 14:55
Hi all,

danke einmal für die vielen Vorschläge.

Hier ein Bericht von 3 Wochen Verbesserungsversuche:
Die Ursache für die hohe Last (hoher IO-Wait, bei nicht zu schnellem Festspeicher) konnte postgrey ausgemacht werden. Etwa die selbe Anzahl von CPU-Zeit benötigen named und postgrey. 1/3 der Zeit beansprucht syslog-ng, 1/4 von postfix.
Häufige Instabilitäten (postgrey timeouts) brachten mich darzu, über Alternativen nachzudenken, zu mal auch des öfteren in Foren von Problemen mit kaputten postgrey Datenbanken berichtet wurden. Nachdem ich das Greylisting nicht aufgeben möchte, testete ich SQLgrey in Kombination mit einer MySQL-DB.
Siehe da, der HD-Zugriff verringerte sich signifikant. Der Mail-GW verbringt viel weniger Zeit mit IO-Wail. Das ganze Arbeiten geht nun viel flüssiger von der Hand. Obwohl die CPU-Last im Mittel nur gering gesunken ist, sind die Wartezeiten auf der Konsole, teilw. bis zu 2-3 Sekunden nach einer Befehlseingabe, beim öffnen einer Datei, u.ae., nahezu verschwunden. Die gefühlte Erhöhung der Geschwindigkeit würde ich auf den Faktor 2 ansetzen.

Chris