[postfix-users] Postfix und mysql verbindungen
Hallo Leute, ich habe da ein Problem, worauf ich in der Doc einfach keine Lösung finde.
Ich benutze einen Postfix-Mailserver als relay-host. An diesen Server sind 2 Application-Server angebunden die Mails versenden. Der Postfix, schaut für
virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf virtual_alias_maps = proxy:mysql:/etc/postfix/mysql-virtual-alias-maps.cf,mysql:/etc/postfix/mysql-email2email.cf
auf einem DB-Server in der Datenbank nach den Alias, Domains etc.
Soweit läuft das auch, nur wenn nun ein höheres Aufkommen >200 Mails/min ist, stagniert mein DB-Server und die Last explodiert. Es scheint so, als ob der Postfix so viele Verbindungen aufbaut, wie er Mails in der Queue hat. Dies wollte ich mit dem proxymap beheben (wie oben zu sehen ist) allerdings ohne Erfolg. Es hat auch den Anschein, dass der Postfix die Verbindungen nicht mehr abbaut, da der RAM stetig ansteigt (auf dem db-server) und nach dem leeren der Queue nicht mehr abgebaut wird.
Was könnte ich dagegen tun ? Gibt es irgendwelche Options die ich evtl. übersehen habe ?
Ich verwende einen Mysql-Server5.0 mit InnoDB auch optimiert.
Ich hoffe hier finde ich brauchbare Tips.
Gruß Heiko
Hallo Heiko,
Am Mittwoch, 29. April 2009 schrieb Heiko Krämer:
Der Postfix, schaut für
virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf virtual_alias_maps = proxy:mysql:/etc/postfix/mysql-virtual-alias-maps.cf,mysql:/etc/postfix/mys ql-email2email.cf
auf einem DB-Server in der Datenbank nach den Alias, Domains etc.
Soweit läuft das auch, nur wenn nun ein höheres Aufkommen >200 Mails/min ist, stagniert mein DB-Server und die Last explodiert. Es scheint so, als ob der Postfix so viele Verbindungen aufbaut, wie er Mails in der Queue hat. Dies wollte ich mit dem proxymap beheben (wie oben zu sehen ist) allerdings ohne Erfolg. Es hat auch den Anschein, dass der Postfix die Verbindungen nicht mehr abbaut, da der RAM stetig ansteigt (auf dem db-server) und nach dem leeren der Queue nicht mehr abgebaut wird.
Was könnte ich dagegen tun ? Gibt es irgendwelche Options die ich evtl. übersehen habe ?
du könntest die Daten in der Datebank regelmäßig per Cronjob oder immer bei Bedarf (Änderung) in Textdateien exportieren, auf die Postfix dann (nach einem postmap) zugreift. Schont die Datenbank enorm...
Gruß, Gregor
Heiko Krämer schrieb:
Hallo Leute, ich habe da ein Problem, worauf ich in der Doc einfach keine Lösung finde.
Ich benutze einen Postfix-Mailserver als relay-host. An diesen Server sind 2 Application-Server angebunden die Mails versenden. Der Postfix, schaut für
virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf virtual_alias_maps = proxy:mysql:/etc/postfix/mysql-virtual-alias-maps.cf,mysql:/etc/postfix/mysql-email2email.cf
auf einem DB-Server in der Datenbank nach den Alias, Domains etc.
Soweit läuft das auch, nur wenn nun ein höheres Aufkommen >200 Mails/min ist
aber ich hab da noch
proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps $virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains $relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps $recipient_canonical_maps $relocated_maps $transport_maps $mynetworks $virtual_mailbox_limit_maps $smtpd_sender_login_maps
proxy_read_maps (default: see "postconf -d" output)
The lookup tables that the proxymap(8) server is allowed to access for the read-only service. Table references that don't begin with proxy: are ignored.
This feature is available in Postfix 2.0 and later.
allerdings kann das natuerlich noch alle moeglichen anderen ursachen haben, nur an den 200 mails per min liegts sicher nicht
, stagniert mein DB-Server und die Last explodiert. Es scheint so, als ob der Postfix so viele Verbindungen aufbaut, wie er Mails in der Queue hat.
Dies wollte ich mit dem proxymap beheben (wie oben zu sehen ist) allerdings ohne Erfolg. Es hat auch den Anschein, dass der Postfix die Verbindungen nicht mehr abbaut, da der RAM stetig ansteigt (auf dem db-server) und nach dem leeren der Queue nicht mehr abgebaut wird.
Was könnte ich dagegen tun ? Gibt es irgendwelche Options die ich evtl. übersehen habe ?
Ich verwende einen Mysql-Server5.0 mit InnoDB auch optimiert.
Ich hoffe hier finde ich brauchbare Tips.
Gruß Heiko
Hi Werner
Warum InnoDB? In der Tabelle/der Datenbank wird ja hauptsächlich lesen zugegriffen, daher würde ich das als MyISAM mit ausreichender key_buffer_size laufen lassen.
Wir benutzen hier auch InnoDB, da unsere Software Transaktionen benutzt beim anpassen. Also wenn was schief läuft (bei unserem Programm) kannst du einfach rollback hintennach schicken und nichts ist passiert...
Andre Keller schrieb:
Hi Werner
Warum InnoDB? In der Tabelle/der Datenbank wird ja hauptsächlich lesen zugegriffen, daher würde ich das als MyISAM mit ausreichender key_buffer_size laufen lassen.
Wir benutzen hier auch InnoDB, da unsere Software Transaktionen benutzt beim anpassen. Also wenn was schief läuft (bei unserem Programm) kannst du einfach rollback hintennach schicken und nichts ist passiert...
Ich wollte keine Grundsatzdiskussion über StorageEngines von MySQL lostreten. Mein Postfix greift nur lesend auf seine Datenbank zu, die Änderungen bzw. Modifikationen in der Datenbank sind relativ gering im Vergleich zum Lesezugriff auf die Tabellen, daher ist bei mir MyISAM optimal. Das wollte ich nur zu bedenken geben :-)
Ciao, Werner
* "Heiko Krämer" postfix-users@de.postfix.org:
Hallo Leute, ich habe da ein Problem, worauf ich in der Doc einfach keine Lösung finde.
Ich benutze einen Postfix-Mailserver als relay-host. An diesen Server sind 2 Application-Server angebunden die Mails versenden. Der Postfix, schaut für
virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf virtual_alias_maps = proxy:mysql:/etc/postfix/mysql-virtual-alias-maps.cf,mysql:/etc/postfix/mysql-email2email.cf
auf einem DB-Server in der Datenbank nach den Alias, Domains etc.
Soweit läuft das auch, nur wenn nun ein höheres Aufkommen >200 Mails/min ist, stagniert mein DB-Server und die Last explodiert. Es scheint so, als ob der Postfix so viele Verbindungen aufbaut, wie er Mails in der Queue hat. Dies wollte ich mit dem proxymap beheben (wie oben zu sehen ist) allerdings ohne Erfolg. Es hat auch den Anschein, dass der Postfix die Verbindungen nicht mehr abbaut, da der RAM stetig ansteigt (auf dem db-server) und nach dem leeren der Queue nicht mehr abgebaut wird.
Also 200 queries/min sind mehr als entspannt, aber eigentlich kein Grund zur Sorge. Ich mein, dafür sind Datenbanken da.
Bist Du Dir sicher, dass Postfix für die Last verantwortlich ist oder löst z.B. ein Shell-Skript bei 200 queries/min dasselbe Verhalten aus?
Was könnte ich dagegen tun ? Gibt es irgendwelche Options die ich evtl. übersehen habe ?
Ich, an Deiner Stelle, würde untersuchen, ob nur Postfix oder irgendeine App MySQL so in Nöte bringen kann. Ggf. kannst Du am Query Cache in MySQL arbeiten. Der ist auf vielen Systemen gar nicht aktiviert...
Ich verwende einen Mysql-Server5.0 mit InnoDB auch optimiert.
Die sollte das gut abkönnen.
p@rick
Hi,
wie stehts denn mit max_connections - ggf. sind die zu gering eingestellt wenn du mit Applikationen und Postfix simultan zugreifst :-)
mysql> show global variables like 'max_connections';
Ist max_connections zu gering eingestellt, kann das ggf. das Bottleneck sein. Wenn die Applikation und Postfix auf die MySQL zugreift aber nicht genügen MySQL-Threads zur Verfügung stehen kann das zu den genannten Problemen führen (Anfragen stauen sich am Webserver wei
Wenn Postfix eine handvoll Verbindungen über den proxy offen hat und dazu die Applikation kann das ggf. zum Bottleneck führen indem einfach alle zur Verfügung stehenden MySQL-Threads zu sind, sich die Anfragen am Webserver aufstauen und die Load fleissig nach oben geht.
Ach, was red ich :-) Ciao, Werner
Hm,
irgendwie fehlt da was in meiner Mail :-)
Ciao, Werner
participants (6)
-
"Heiko Krämer" -
Andre Keller -
Gregor Hermens -
Patrick Ben Koetter -
Robert Schetterer -
Werner Detter