Postfix MySQL langsames delivery

C

ceebes

New Member
Hallo zusammen!!

Mein System:
Debian 4.0 etch
postfix 3.1
MySQL 5.1
spamassasin
avamisd
clamav
ca 5000 Mailkonten
5 MySQL tabellen mit restrictions und userdaten
cpu im schnitt 60 % idle
hardware ist neuere dualcore ibm maschine, spez. habe ich nicht im kopf...

Mein Problem:
Postfix liefert die Mails nur sehr langsam aus. dadurch steigt die mailq langsam und stetig an. die mysql querys liegen bei ca 130/sek
geblockt werden die meisten absender mit recipient_restrictions bereits beim eintreffen mit NOQUEUE. Diese restrictions werden natürlich alle aus der mysql db gezogen.
Testweise blocke ich mit iptables alle externen smtp verbindungen, so dass postfix die queue abarbeiten kann, dann sinken ebenfalls die querys auf ca 30/sek.

nun meine Vermutungen:
-mysql ist nicht optimal konfiguriert
-Die Hardware ist zu lahm
-spamassasin und konsorten bremsen den server
-... hab leider keine ideen mehr...!!

Ich denke ja mal das so ein fall mit 5000 konten mit meiner software konfiguration keine aussergewöhnliche sache ist!
Was könnte ich anpassen?
für jegliche tips bin ich sehr dankbar!!!
 
Sprechen wir von Postfix Restrictions? Falls ja: Zeig mal bitte deine Config und die Restrictions an sich!
 
hy marco

hier die postfix main.cf:
Code: 
smtpd_banner = $myhostname ESMTP
biff = no

append_dot_mydomain = no

mydomain = xxxx.ch

myorigin = /etc/mailname
mydestination = $myhostname, $mydomain, localhost.$mydomain, localhost, $transport_maps
relayhost =
mynetworks = 127.0.0.0/8, 213.213.160.0/19

maximal_queue_lifetime = 1d
bounce_queue_lifetime = 1h

in_flow_delay = 10s
max_use = 300

notify_classes = software

message_size_limit = 20480000
mailbox_size_limit = 30000000
recipient_delimiter = +
inet_interfaces = all

virtual_transport = smtp

home_mailbox = Maildir/

alias_maps = mysql:/etc/postfix/mysql-aliases.cf
relocated_maps = mysql:/etc/postfix/mysql-relocated.cf
transport_maps = mysql:/etc/postfix/mysql-transport.cf
virtual_maps = mysql:/etc/postfix/mysql-virtual.cf
#
local_recipients_maps = $alias_maps $virtual_mailbox_maps unix:passwd.byname

#
virtual_mailbox_base = /home/vmail
virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual-maps.cf
virtual_uid_maps = mysql:/etc/postfix/mysql-virtual-uid.cf
virtual_gid_maps = mysql:/etc/postfix/mysql-virtual-gid.cf
#
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
#
unknown_local_recipient_reject_code = 550
#
smtpd_client_restrictions = check_client_access mysql:/etc/postfix/mysql-client.cf

smtpd_recipient_restrictions =  check_recipient_access mysql:/etc/postfix/mysql-recipient.cf,
                                permit_sasl_authenticated,
                                reject_unauth_destination,
                                permit_mynetworks,
                                reject_rbl_client dev.null.dk,
                                reject_rbl_client sbl.spamhaus.org
                                                                                                                     


#
maildrop_destination_concurrency_limit = 1
maildrop_destination_recipient_limit = 1


smtpd_discard_ehlo_keywords = silent-discard, dsn

smtpd_sender_restrictions und smtpd_ehlo_restrictions sind keine zu finden in der config...

so wie ich das sehe erzeugt check_recipient_access die hohe mysql last, da doch recht viele mails an nicht vorhandene user eingehen "wollen".
 
Last edited by a moderator:
Hy Huschi

hier mein top auszug
Code: 
top - 09:01:46 up 16:49,  2 users,  load average: 2.21, 2.35, 2.40
Tasks: 351 total,   1 running, 350 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.8%us,  1.4%sy,  0.0%ni, 72.4%id, 24.2%wa,  0.0%hi,  0.2%si,  0.0%st
Mem:   1026432k total,  1007064k used,    19368k free,   174024k buffers
Swap:  2650684k total,       52k used,  2650632k free,   279808k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 3029 mysql     15   0  190m  68m 5088 S    4  6.8  14:40.11 mysqld
 1784 postfix   15   0  7868 2996 1896 S    2  0.3   0:08.88 trivial-rewrite
 3099 amavis    18   0  5952 3668 2008 S    1  0.4   0:00.04 pyzor
19758 root      15   0  4812 1628 1296 S    1  0.2   0:19.48 master
 2426 amavis    15   0 61508  50m 2920 S    1  5.0   0:02.10 amavisd-new
 3085 root      15   0  2364 1308  856 R    1  0.1   0:00.14 top
 1159 root      10  -5     0    0    0 D    0  0.0   4:02.44 kjournald
 5374 root      18   0  1624  640  512 D    0  0.1   2:40.23 syslogd
 1795 postfix   15   0  7552 2528 1636 S    0  0.2   0:00.91 anvil
 1860 postfix   15   0  9816 3488 2632 S    0  0.3   0:00.16 smtpd
 1965 postfix   18   0  9824 3496 2632 S    0  0.3   0:00.23 smtpd
 2664 postfix   16   0  9832 3460 2632 S    0  0.3   0:00.08 smtpd
 2692 postfix   18   0  9808 3444 2644 S    0  0.3   0:00.06 smtpd
 2979 amavis    18   0 58124  47m 2908 S    0  4.7   0:00.58 amavisd-new
    1 root      15   0  1948  640  544 S    0  0.1   0:01.56 init
    2 root      RT   0     0    0    0 S    0  0.0   0:00.26 migration/0
    3 root      36  19     0    0    0 S    0  0.0   0:00.00 ksoftirqd/0
    4 root      RT   0     0    0    0 S    0  0.0   0:00.18 migration/1
    5 root      34  19     0    0    0 S    0  0.0   0:00.04 ksoftirqd/1
    6 root      RT   0     0    0    0 S    0  0.0   0:18.53 migration/2
    7 root      34  19     0    0    0 S    0  0.0   0:00.00 ksoftirqd/2
    8 root      RT   0     0    0    0 S    0  0.0   0:01.40 migration/3
    9 root      34  19     0    0    0 S    0  0.0   0:00.07 ksoftirqd/3
   10 root      10  -5     0    0    0 S    0  0.0   0:00.04 events/0
   11 root      10  -5     0    0    0 S    0  0.0   0:00.01 events/1
   12 root      10  -5     0    0    0 S    0  0.0   0:00.00 events/2
   13 root      10  -5     0    0    0 S    0  0.0   0:00.00 events/3
   14 root      10  -5     0    0    0 S    0  0.0   0:00.00 khelper
   15 root      14  -5     0    0    0 S    0  0.0   0:00.00 kthread
   21 root      10  -5     0    0    0 S    0  0.0   0:00.12 kblockd/0
   22 root      10  -5     0    0    0 S    0  0.0   0:00.06 kblockd/1
   23 root      10  -5     0    0    0 S    0  0.0   0:00.51 kblockd/2
   24 root      10  -5     0    0    0 S    0  0.0   0:00.00 kblockd/3
   25 root      19  -5     0    0    0 S    0  0.0   0:00.00 kacpid
  127 root      10  -5     0    0    0 S    0  0.0   0:00.00 kseriod
  165 root      24   0     0    0    0 S    0  0.0   0:00.00 pdflush
  166 root      15   0     0    0    0 S    0  0.0   0:03.06 pdflush
  167 root      10  -5     0    0    0 S    0  0.0   0:09.19 kswapd0
  168 root      20  -5     0    0    0 S    0  0.0   0:00.00 aio/0
  169 root      20  -5     0    0    0 S    0  0.0   0:00.00 aio/1
  170 root      10  -5     0    0    0 S    0  0.0   0:00.00 aio/2
  171 root      13  -5     0    0    0 S    0  0.0   0:00.00 aio/3
  313 root      15   0     0    0    0 S    0  0.0   0:00.04 kirqd
  702 root      18  -5     0    0    0 S    0  0.0   0:00.00 khubd
  746 root      11  -5     0    0    0 S    0  0.0   0:00.00 scsi_eh_0
  773 root      12  -5     0    0    0 S    0  0.0   0:00.00 scsi_eh_1
 1338 root      16  -4  2180  600  344 S    0  0.1   0:00.09 udevd
 1717 root      16  -5     0    0    0 S    0  0.0   0:00.00 kpsmoused
 4960 root      13  -5     0    0    0 S    0  0.0   0:00.00 kmirrord
 5395 root      15   0  1580  376  308 S    0  0.0   0:00.01 klogd
 
Die MySQL Prüfung ganz am Anfang smtpd_recipient_restrictions will mir da so gar nicht gefallen... Das ist eine der teuersten Abfragen und bei dir wird sie für ausnahmslos jede Mail verwendet...

Was bezweckt diese Abfrage denn konkret? Ich hoffe nicht, dass du damit abfrägst welche User existieren und welche nicht :)
 
Code: 
smtpd_recipient_restrictions =  check_recipient_access mysql:/etc/postfix/mysql-recipient.cf,
                                permit_sasl_authenticated,
                                reject_unauth_destination,
                                permit_mynetworks,
                                reject_rbl_client dev.null.dk,
                                reject_rbl_client sbl.spamhaus.org

Woops, doch, die prüft ob die clients existieren.
Ich habe allerdings die restrictions vorhin noch kurz angepasst.
Hier eine "testing" main.cf... nicht perfekt, keine rbl usw.
Code: 
smtpd_client_restrictions = reject_unknown_client
			    reject_unauth_pipelining
			    #reject_rbl_client relays.ordb.org
			    #reject_rbl_client dev.null.dk
			    #reject_rbl_client opm.blitzed.org
			    #reject_rbl_client sbl.spamhaus.org
			    permit_mynetworks

smtpd_helo_restrictions = reject_non_fqdn_hostname
			  reject_invalid_hostname

smtpd_sender_restrictions = reject_unknown_sender_domain
			    reject_unknown_hostname
			    #reject_unknown_client
			    #reject_non_fqdn_sender
			    #reject_non_fqdn_hostname
			    #permit_mynetworks

smtpd_recipient_restrictions =  check_recipient_access mysql:/etc/postfix/mysql-recipient.cf
			        permit_sasl_authenticated
				reject_unauth_destination
				permit_mynetworks
 
ceebes said:
Postfix liefert die Mails nur sehr langsam aus.
Click to expand...
Hier stellt sich die Frage:
Wie langsam? (Belege aus dem Logfile...)

Die Speicherbelegung ist zumindest ok.

check_recipient_access mysql:/etc/postfix/mysql-recipient.cf
Click to expand...
Wie sieht dieser SQL aus?
Und wie sehen die anderen aus?

An sich muß das ganze Maillog untersucht werden um rauszufinden, wo die Zeitverzögerung auftritt.
Aber dafür ist das Board nicht der richtige Ort.

huschi.
 
Hallo :)

Die neuen Restriktionen gefallen mir schon besser :) Aber du hast noch immer die MySQL Abfrage drin die IMO unnötig ist :)

Ich erreiche nämlich genau das was du machen willst ohne auf MySQL zurückzugreifen:

Code: 
smtpd_recipient_restrictions =
    reject_non_fqdn_sender
    reject_unknown_sender_domain
    reject_non_fqdn_recipient
    reject_unknown_recipient_domain
    permit_mynetworks
    permit_sasl_authenticated
    reject_unauth_destination
    [... noch viel viel mehr ...]

[ot]Mir ist gerade aufgefallen dass Ralf Hildebrandt u.a. in seinem Buch grundsätzlich nur die smtpd_recipient_restrictions verwendet und keine anderen. Hat dafür jemand eine Erklärung? Mir erscheint das nur insofern logisch als dass Postfix die Behandlung der Restrictions generell bis zum ersten Empfänge verzögert, da einige Clients ein sofortiges Nein nicht akzeptieren. Weil man dieses Verhalten aber ausschalten kann (Restrictions greifen sofort nach Clientangabe), nehme ich an dass er das an die Stelle packt.[/ot]

Gruß,

Marco
 
hier die sql query von
check_recipient_access mysql:/etc/postfix/mysql-recipient.cf
Code: 
user = mysql
password = xxxx
dbname = postfix
table = access
select_field = access
where_field = source
additional_conditions = and type = 'recipient'
hosts = 127.0.0.1

hier ein paar zeilen des mail.log
-> status=sent
Code: 
Nov 13 10:27:15 mail postfix/smtp[13318]: 3537B1AFCBC8: to=<ushma@lula.ch>, relay=127.0.0.1[127.0.0.1]:10024, delay=2871, delays=2035/815/0/22, dsn=2.6.0, status=sent (250 2.6.0 Ok, id=15160-10, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 7DA0F5441AA)
Nov 13 10:27:19 mail postfix/virtual[14094]: 3D0601AFCDD5: to=<gerda.kramis@lula.ch>, relay=virtual, delay=1019, delays=1005/14/0/0.11, dsn=2.0.0, status=sent (delivered to maildir)
Nov 13 10:27:28 mail postfix/virtual[13118]: 018801AFCDFD: to=<spilka@zapp.ch>, relay=virtual, delay=552, delays=543/8.9/0/0.11, dsn=2.0.0, status=sent (delivered to maildir)
Nov 13 10:27:30 mail postfix/smtp[13124]: 9DF7F5440DC: to=<Karine.Heude@terex-demag.com>, relay=127.0.0.1[127.0.0.1]:10024, delay=934, delays=84/821/0/29, dsn=2.6.0, status=sent (250 2.6.0 Ok, id=15225-10, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as CD6EC5441B5)
mail:/etc/postfix# tail -500 /var/log/mail.log | grep status=sent
Nov 13 10:27:14 mail postfix/virtual[13115]: 9D1851AFCF25: to=<cometo@zapp.ch>, relay=virtual, delay=408, delays=396/12/0/0.13, dsn=2.0.0, status=sent (delivered to maildir)
Nov 13 10:27:15 mail postfix/smtp[13318]: 3537B1AFCBC8: to=<ushma@lula.ch>, relay=127.0.0.1[127.0.0.1]:10024, delay=2871, delays=2035/815/0/22, dsn=2.6.0, status=sent (250 2.6.0 Ok, id=15160-10, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 7DA0F5441AA)
Nov 13 10:27:19 mail postfix/virtual[14094]: 3D0601AFCDD5: to=<gerda.kramis@lula.ch>, relay=virtual, delay=1019, delays=1005/14/0/0.11, dsn=2.0.0, status=sent (delivered to maildir)
Nov 13 10:27:28 mail postfix/virtual[13118]: 018801AFCDFD: to=<spilka@zapp.ch>, relay=virtual, delay=552, delays=543/8.9/0/0.11, dsn=2.0.0, status=sent (delivered to maildir)
Nov 13 10:27:30 mail postfix/smtp[13124]: 9DF7F5440DC: to=<Karine.Heude@terex-demag.com>, relay=127.0.0.1[127.0.0.1]:10024, delay=934, delays=84/821/0/29, dsn=2.6.0, status=sent (250 2.6.0 Ok, id=15225-10, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as CD6EC5441B5)
Nov 13 10:27:37 mail postfix/virtual[13115]: D814E5440FF: to=<charles@zapp.ch>, relay=virtual, delay=821, delays=810/11/0/0.1, dsn=2.0.0, status=sent (delivered to maildir)
Nov 13 10:27:37 mail postfix/smtp[13382]: 05DEE1AFCFCD: to=<barbouze@zapp.ch>, relay=127.0.0.1[127.0.0.1]:10024, delay=1657, delays=798/840/0/19, dsn=2.6.0, status=sent (250 2.6.0 Ok, id=15687-04, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 35EEF5441C3)

Wie erreiche ich ein nopaste hier im Forum? bin neu hier... :o
 
Gleich noch ne Frage: Wie ist der Wiedereintritt nach Amavis (? localhost:10024) konfiguriert? Denkbar wäre hier nämlich auch, dass du NOCHMAL die MySQL Queries anstartest - was ja nicht notwendig ist :)
 
Marco said:
grundsätzlich nur die smtpd_recipient_restrictions verwendet und keine anderen. Hat dafür jemand eine Erklärung?
Click to expand...
Im Normalfall reichen die aus.
Wie Du selbst gesagt hast: Viele (schlecht programmierte) Server und Clients reagieren erst nach dem RCPT TO auf eine negative Antwort.
Irgendwo hab ich auch mal gelesen warum. Der Grund war durchaus einleuchtend... :confused:

ceebes said:
hier die sql query
Click to expand...
Nichts aufwendiges, sollte also überwiegend gecached werden.

hier ein paar zeilen des mail.log
Click to expand...
Du mußt schon ein bisschen für uns filtern.
Verfolge wirklich ein oder zwei Emails mit all ihren Logeinträgen und pack die vernünftig unter einander.

Wie erreiche ich ein nopaste hier im Forum?
Click to expand...
Mit nopaste.com und einem URL-Link. :)

ceebes said:
ja, dies ist via port 10024 gelöst.
wie könnte ich das fixen?
Click to expand...
Zeig Deine master.cf.

huschi.
 
Nein, Postfix sollte das so packen, auch mit MySQL.

Deine master.cf ist auch sauber - der "Wiedereintritt" läuft nicht nochmal gegen MySQL.

Irgendwie habe ich hier aber auch gerde Verständnisprobleme: Willst du dich absichern dass dein Server keine Mails annimmt für Empfänger die es bei dir nicht gibt oder willst du nur bestimmten Absendern erlauben bestimmten Empfängern eine E-Mail zu schreiben (das entnehme ich gerade deiner SQL Query ...)?

PS: Ich bin seit ner Stunde an nem dummen SAP Problem an einem unserer Server dran. Hab hier evtl. grad nicht mehr nen ganz unverbrauchten Blick auf die Sache :)
 
ceebes said:
Hier das log eines mails.
Click to expand...
Naja, daß hätte auch in CODE-Tags direkt in das Posting gepasst. ;)
Allerdings stimmen hier die Zeiten und Zeilen nicht. Prüf das nochmal, denn ich denke, dieses Einträge gehören nicht alle zur selben Email bzw. eine Zeile ist sogar doppelt.

ist es nicht praktikabel einen mailserver mit 5000 konten, mit mysql backend auf einem server mit obiger auslastung zu betreiben?
Click to expand...
Kommt drauf an, was Du sonst noch auf dem Server betreibst... :)
Aber laut Deinem top-Auszug ist der Server bei nicht wirklich ausgelastet.

huschi.
 
Hätte mich auch erstaunt, wenn postfix dies nicht packen würde...
5000 boxen sind ja nun auch nicht die welt...

Deine erste Aussage ist richtig.
Ich will dass der Server keine Mails annimmt an user die es auf dem server nicht gibt.
Die zweite aussage ist meines erachtens nicht sehr praktikabel...??

hab die query von oben angepasst:

user = mysql
password = umY2lq
dbname = postfix
table = users
select_field = email
where_field = email
additional_conditions = and access = 'Y'
hosts = 127.0.0.1
 
Last edited by a moderator:
Ok, aber genau das erreiche ich auch mit Standard Restriktionen ohne auf MySQL zurückgreifen zu müssen. :)
 
ja ich hab die restrictions angepasst, und die mysql querys minimiert, denke nun dass mysql keine probleme mehr macht.
postfix liefert die mails einfach extrem langsam aus...
wenn ich mit iptables nur mein internes netz auf den smtp zulasse, werden die nachrichten schnell abgearbeitet...
wenn aber der server offen ist, steigt die queue langsam an...
es werden sehr viele mails rejected, doch so wie es aussieht frisst dies und amavis sehr viel system performance!

langsam gehen mir effektiv die ideen aus!
 
Reden wir doch mal Klartext:
Welche Emails werden langsamer ausgeliefert? Die reinkommenden oder ausgehenden?
Und welche (messbare / nachweißbare) Zeitverzögerung hast Du denn? (Die Logfiles sind immer noch nicht aussagekräftig.)
Wie viele Emails liegen in der Mail-Queue?

huschi.
 
You must log in or register to reply here.
Back
Top