[postfix-users] proxymap Prozesse tunen?
Tach zusammen,
erstmal zum Verständnis:
ist es korrekt, dass es jeweils genau einen proxymap Prozess für jede in der main.cf referenenzierten "proxy:blubber:...." gibt? d.h Änderungen in der master.cf unter MaxProcs für proxy werden ignoriert..?
Und jetzt zur eigentlichen Frage:
Hier laufen im moment insgesamt 10 proxymap-Prozesse und jeder steht im top mit CPU-Werten zwischen 10% und 20% (das ist ne 2-vCPU-VM auf ESX)
irgendwie ist mein System also zu 90% mit proxymap-Prozessen beschäftigt - und das alles auf CPU... was zum Geier muss der abfragende Client bei ner SQL-Abfrage denn so gross "rechnen".. das macht doch der DB-Server der gefragt wird..
Und kann man da was tunen..?
Oder die max. Anzahl an zulässigen Verbindungen zur Datenbank erhöhen, den Postfix aus der chroot befreien und kein proxymap verwenden als einzige Möglichkeit..?
Eingebaut sind die Lookups in smtpd_recipient_restrictions, relay_domains, transport_maps und virtual_alias_maps
Christian
Christian Bricart schrieb:
Tach zusammen,
erstmal zum Verständnis:
ist es korrekt, dass es jeweils genau einen proxymap Prozess für jede in der main.cf referenenzierten "proxy:blubber:...." gibt? d.h Änderungen in der master.cf unter MaxProcs für proxy werden ignoriert..?
Und jetzt zur eigentlichen Frage:
Hier laufen im moment insgesamt 10 proxymap-Prozesse und jeder steht im top mit CPU-Werten zwischen 10% und 20% (das ist ne 2-vCPU-VM auf ESX)
irgendwie ist mein System also zu 90% mit proxymap-Prozessen beschäftigt - und das alles auf CPU... was zum Geier muss der abfragende Client bei ner SQL-Abfrage denn so gross "rechnen".. das macht doch der DB-Server der gefragt wird..
Und kann man da was tunen..?
Oder die max. Anzahl an zulässigen Verbindungen zur Datenbank erhöhen, den Postfix aus der chroot befreien und kein proxymap verwenden als einzige Möglichkeit..?
Eingebaut sind die Lookups in smtpd_recipient_restrictions, relay_domains, transport_maps und virtual_alias_maps
Christian
postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Hi, wie ist denn dein setup, deine Beschreibung ist zu allgemein lass mal main.cf master cf sehen, postfix version um wie viele user/domains handelt es sich, datendurchsatz usw und bist du dir sicher dass du smtpd_recipient_restrictions in einer db hast , das ist zumindest sehr ungewohnlich und irgendwie kann ich mir diese tabelle auch nicht vorstellen, bzw was bringt das? das sieht doch normalerweise eher so aus
smtpd_recipient_restrictions = check_recipient_access hash:/etc/postfix/recipient_access_blacklist, reject_unknown_recipient_domain, reject_non_fqdn_recipient, permit_mynetworks, reject_unlisted_recipient, usw
warum sollte man sowas in einer db machen....(mal abgesehen das es doch unnoetig kompliziert waere, und ob man da drauf noch ein proxy machen kann bezweifele ich ( oder zumindest wuerde es mich sehr verwirren) , weil das ja parameter sind, und keine maps
im vergleich taucht proxy in meinen top so gut wie gar nie auf, so wenig last wird da erzeugt ( aber das haengt wohl auch mit der Anzahl der Userzusammen , der Anfragen usw )
Robert Schetterer wrote:
[..]
Hi, wie ist denn dein setup, deine Beschreibung ist zu allgemein lass mal main.cf master cf sehen, postfix version
master.cf ist quasi unverändert von Debian Etch damit auch: mail_version = 2.3.8
um wie viele user/domains handelt es sich, datendurchsatz usw
Auszug aus "pflogsumm -d yesterday -u 0": Grand Totals ------------ messages
8479 received 6871 delivered 0 forwarded 273 deferred (685 deferrals) 0 bounced 81120 rejected (92%) 0 reject warnings 0 held 0 discarded (0%)
1234m bytes received 1310m bytes delivered 1526 senders 1284 sending hosts/domains 1008 recipients 19 recipient hosts/domains
aber das ist nur einer von im moment dreien...
und bist du dir sicher dass du smtpd_recipient_restrictions in einer db hast , das ist zumindest sehr ungewohnlich und irgendwie kann ich mir diese tabelle auch nicht vorstellen, bzw was bringt das?
Ja - bin ich mir sicher ;-)
prinzipiell stehen dort einige "check_recipient_access proxy:pgsql:..." drin, die z.B nötige restriction_classes erfragen - die ein Kunde gebucht hat.. oder eben auch nicht, die dann zusätzlich eingeschoben werden. Und einige White- und Blacklisten - das übliche eben.. nur hier kommen die "üblichen" Hash-Dateien halt aus ner Datenbank.
Ach ja Und es gibt auf der Datenbank keine einzige Query, die länger als 3ms dauert.. dort ist also kein Bottleneck..
warum sollte man sowas in einer db machen....(mal abgesehen das es doch unnoetig kompliziert waere, und ob man da drauf noch ein proxy machen kann bezweifele ich ( oder zumindest wuerde es mich sehr verwirren) , weil das ja parameter sind, und keine maps
der Grund ist einfach eine zentrale Administration eines Mailserver-Clusters. Die Konfiguration eines Nodes ist damit statisch und kann einfach geklont werden.
Und Proxy um nicht alle (Anzahl) möglichen smtpd-Prozesse aller Mailserver jeweils eine Connection zur Datenbank machen zu lassen - das war doch der/ein Sinn von proxymap..
Christian
Christian Bricart schrieb:
Robert Schetterer wrote:
[..]
Hi, wie ist denn dein setup, deine Beschreibung ist zu allgemein lass mal main.cf master cf sehen, postfix version
master.cf ist quasi unverändert von Debian Etch damit auch: mail_version = 2.3.8
um wie viele user/domains handelt es sich, datendurchsatz usw
Auszug aus "pflogsumm -d yesterday -u 0": Grand Totals
messages
8479 received 6871 delivered 0 forwarded 273 deferred (685 deferrals) 0 bounced 81120 rejected (92%) 0 reject warnings 0 held 0 discarded (0%)
1234m bytes received 1310m bytes delivered 1526 senders 1284 sending hosts/domains 1008 recipients 19 recipient hosts/domains
aber das ist nur einer von im moment dreien...
und bist du dir sicher dass du smtpd_recipient_restrictions in einer db hast , das ist zumindest sehr ungewohnlich und irgendwie kann ich mir diese tabelle auch nicht vorstellen, bzw was bringt das?
Ja - bin ich mir sicher ;-)
prinzipiell stehen dort einige "check_recipient_access proxy:pgsql:..." drin, die z.B nötige restriction_classes erfragen - die ein Kunde gebucht hat.. oder eben auch nicht, die dann zusätzlich eingeschoben werden. Und einige White- und Blacklisten - das übliche eben.. nur hier kommen die "üblichen" Hash-Dateien halt aus ner Datenbank.
Ach ja Und es gibt auf der Datenbank keine einzige Query, die länger als 3ms dauert.. dort ist also kein Bottleneck..
warum sollte man sowas in einer db machen....(mal abgesehen das es doch unnoetig kompliziert waere, und ob man da drauf noch ein proxy machen kann bezweifele ich ( oder zumindest wuerde es mich sehr verwirren) , weil das ja parameter sind, und keine maps
der Grund ist einfach eine zentrale Administration eines Mailserver-Clusters. Die Konfiguration eines Nodes ist damit statisch und kann einfach geklont werden.
Und Proxy um nicht alle (Anzahl) möglichen smtpd-Prozesse aller Mailserver jeweils eine Connection zur Datenbank machen zu lassen - das war doch der/ein Sinn von proxymap..
Christian
postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Hallo Christian
mail_version = 2.3.8 ist schon ziemlich alt aktuell waere 2.5.3 aber das duerfte nicht das Problem sein ( zumindest wuesste ich von keinem, evtl mal changelog durchsuchen nach proxy ) trotzdem ist nicht ausgeschlossen das sich im code etwas geaendert hat, ich wuerde mal upgraden, ich weiss zwar nicht was grade bei etch so moeglich ist aber mind 2.4 sollte per holbar sein vermute ich in unstable sid ist 2.5.2 das habe ich heute gecheckt. Ich benutze mysql, also kann ich wenig ueber die performance von pgsql sagen, der traffic kann es nicht sein bei dem bissl was du da hast und du hast recht die db abfrage sollte durch proxy sozusagen gecached werden, was mich verwirrt ist dass du ueberhaupt soviel proxy prozesse hast,
ich hab das zb so in main.cf vergleich mal rein der syntax wegen
---snip
relay_domains = proxy:mysql:/etc/postfix/mysql_relay_domains_maps.cf virtual_mailbox_limit_maps = proxy:mysql:/etc/postfix/mysql_virtual_mailbox_limit_maps.cf
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
in master.cf
proxymap unix - - n - - proxymap
ach ja bei ubuntu war ich letzthin sehr verduzt weil die alles chrooted hatten als default, gugg mal nach so reine kontrolle, nicht das da irgendwo ein prob ist
zum anderen koennte es natuerlich sein das trotz proxy eine unglueckliche regelanordnung gemacht hast, jede mail muss ja letzendlich fast das komplette regelwerk durchlaufen = Abfrage in der db evtl gibts da einen timeout irgendwann ( fehler in einer Tabelle etc) und dann forked das ganze evtl und schaukelt sich hoch in diesem Fall wuerde ein proxy nicht viel nutzen, und ganze ehrlich, ich versteh zwar was und warum du das so macht , und ich halte es auch grundsaetzlich nicht fuer falsch aber gesehen hab ich so ein setup eigentlich noch nicht, und ich wuerde das wohl auch anders loesen bzw mich auf setups zurueckziehen die gebraeuchlicher sind.
leider kann ich dazu nicht mehr sagen, weil ich damit noch nie ein Problem hatte und das selbst auf meinem groessten Server mit 2000 Usern problemlos laeuft, versuch mal die engl. sprachige postfix liste ich koennten mir denken da bekommst du prompt eine Antwort
Robert Schetterer wrote:
[..]
[..] was mich verwirrt ist dass du ueberhaupt soviel proxy prozesse hast,
ich hab das zb so in main.cf vergleich mal rein der syntax wegen [..]
naja - viel falsch machen kann man ja da nicht ;-)
ich glaube, dass du weniger Prozesse dort hast würde meine erste Frage zu Anfang bestätigen, dass es pro Definition eines proxymap-Lookups genau einen Prozess gibt und man dort die Anzahl nicht beeinflussen kann. Du hast ja nur zwei proxy:... Aufrufe in deiner main.cf - ergo nur zwei Prozesse ;-)
[..] ach ja bei ubuntu war ich letzthin sehr verduzt weil die alles chrooted hatten als default, gugg mal nach so reine kontrolle, nicht das da irgendwo ein prob ist
öhm - etwa auch "proxy"..? Das ist doch der Witz dabei, dass genau _der_ nicht chrooted ist..
Aber nein - alles ok hier
zum anderen koennte es natuerlich sein das trotz proxy eine unglueckliche regelanordnung gemacht hast, jede mail muss ja letzendlich fast das komplette regelwerk durchlaufen = Abfrage in der db evtl gibts da einen timeout irgendwann ( fehler in einer Tabelle etc) und dann forked das ganze evtl und schaukelt sich hoch in diesem Fall wuerde ein proxy nicht viel nutzen,
weder Errors noch Warnings sowohl im Postfix-Log als auch im PostgreSQL-Log
und ganze ehrlich, ich versteh zwar was und warum du das so macht , und ich halte es auch grundsaetzlich nicht fuer falsch aber gesehen hab ich so ein setup eigentlich noch nicht, und ich wuerde das wohl auch anders loesen bzw mich auf setups zurueckziehen die gebraeuchlicher sind.
Ich komme gerade von einem Setup, welches ständig lokale Dateien hin- und her-ge-rsync-t hat und sich periodisch besser den Inhalt des zentralen LDAP in lokale Maps gedumpt hat, als irgendwo auf eine zentrale Verwaltung (LDAP, DB, ..) direkt zuzugreifen - das ist irgendwann nicht mehr übersichtlich ;-)
vorallem dann nicht, wenn man Inbound- und Outbound-Server trennt und einige andere Sachen noch zusätzlich macht, die eben nicht "normal" sind.. das soll ja gerade der Mehrwert sein ;-)
leider kann ich dazu nicht mehr sagen, weil ich damit noch nie ein Problem hatte und das selbst auf meinem groessten Server mit 2000 Usern problemlos laeuft, versuch mal die engl. sprachige postfix liste ich koennten mir denken da bekommst du prompt eine Antwort
aha - lokale User bei dir? Hier ist die Anzahl der User ganz genau: Null ;-) Das hier ist ne "Mailschubse" für andere Leute ;-)
Christian
Hallo Christian
Christian Bricart schrieb:
Robert Schetterer wrote:
[..]
[..] was mich verwirrt ist dass du ueberhaupt soviel proxy prozesse hast,
ich hab das zb so in main.cf vergleich mal rein der syntax wegen [..]
naja - viel falsch machen kann man ja da nicht ;-)
ich glaube, dass du weniger Prozesse dort hast würde meine erste Frage zu Anfang bestätigen, dass es pro Definition eines proxymap-Lookups genau einen Prozess gibt und man dort die Anzahl nicht beeinflussen kann. Du hast ja nur zwei proxy:... Aufrufe in deiner main.cf - ergo nur zwei Prozesse ;-)
stimmt nicht, ich habe nur einen proxy prozess und natuerlich habe ich mehrere proxy Eintraege ( nicht nur 2) das gepostete main.cf war nur gekuerzt ich dachte das recht als beispiel fuer die syntax
[..] ach ja bei ubuntu war ich letzthin sehr verduzt weil die alles chrooted hatten als default, gugg mal nach so reine kontrolle, nicht das da irgendwo ein prob ist
öhm - etwa auch "proxy"..? Das ist doch der Witz dabei, dass genau _der_ nicht chrooted ist..
Aber nein - alles ok hier
zum anderen koennte es natuerlich sein das trotz proxy eine unglueckliche regelanordnung gemacht hast, jede mail muss ja letzendlich fast das komplette regelwerk durchlaufen = Abfrage in der db evtl gibts da einen timeout irgendwann ( fehler in einer Tabelle etc) und dann forked das ganze evtl und schaukelt sich hoch in diesem Fall wuerde ein proxy nicht viel nutzen,
weder Errors noch Warnings sowohl im Postfix-Log als auch im PostgreSQL-Log
du kannst das ja mal mit postmap per hand testen
und ganze ehrlich, ich versteh zwar was und warum du das so macht , und ich halte es auch grundsaetzlich nicht fuer falsch aber gesehen hab ich so ein setup eigentlich noch nicht, und ich wuerde das wohl auch anders loesen bzw mich auf setups zurueckziehen die gebraeuchlicher sind.
Ich komme gerade von einem Setup, welches ständig lokale Dateien hin- und her-ge-rsync-t hat und sich periodisch besser den Inhalt des zentralen LDAP in lokale Maps gedumpt hat, als irgendwo auf eine zentrale Verwaltung (LDAP, DB, ..) direkt zuzugreifen - das ist irgendwann nicht mehr übersichtlich ;-)
naja normalerweise aendert sich ja nicht soviel be den restrictions, da ist ein file sync schon ok, fuer die user und domains etc gibts ja webinterfaces ( zb postfixadmin ) und zb blacklists die ein user selbst bearbeiten kann loest man wohl besser ueber einen policy server , der dann wiederum natuerlich sql oder ldap befragen kann, horde-ingo hat sowas zb um einen reject auf smtp level zumachen, das kann der user dann selbst einstellen wenn er will, aber ist auch egal das ist ja eigentlich nicht dein Problem
vorallem dann nicht, wenn man Inbound- und Outbound-Server trennt und einige andere Sachen noch zusätzlich macht, die eben nicht "normal" sind.. das soll ja gerade der Mehrwert sein ;-)
whatever, es kommt halt darauf an was man damit bezweckt und ich kann mir keine sinnvolle Anwendung ausser user gesteuerte rejects vorstellen, zum Anlegen , Loeschen etc von usern gibts ja interfaces, ob man da inbound oder outbound trennt ist zweitrangig wen man ldap oder sql nutzt, es ist nur die Frage was man da ausser domain, user, transport noch alles reinschiebt und ob das sinn macht bzw ob man ueberhaupt will das diese parameter von jemanden anderem ausser dem postmaster beeinflussbar sind wie schon erwaehnt ich halte es ja nicht fuer falsch sondern nur fuer ungewoehnlich
leider kann ich dazu nicht mehr sagen, weil ich damit noch nie ein Problem hatte und das selbst auf meinem groessten Server mit 2000 Usern problemlos laeuft, versuch mal die engl. sprachige postfix liste ich koennten mir denken da bekommst du prompt eine Antwort
aha - lokale User bei dir? Hier ist die Anzahl der User ganz genau: Null ;-) Das hier ist ne "Mailschubse" für andere Leute ;-)
na vmail, alles macht vmail das ist der einzige lokale user der was mit mail zu schaffen hat ausser natuerlich die accounts die normalerweise immer enthalten sind postfix etc
gugg mal da so hab ich das ungefaehr ( uebrigens auch mit getrennten servern allerdings fuer backup mx )
http://wiki.dovecot.org/HowTo/DovecotLDAPostfixAdminMySQL?highlight=(postfix...)
dazu horde und man hat eigentlich alles was man braucht zumindest faellt mir da eigentlich nicht viel ein was man sonst benoetigen wuerde , da hat man sieve als filter , jeder kann seine amavis spamassassin selber machen ( in in sql), syncml usw, es gibt da natuerlich elend viele andere Moeglichkeiten, aber die hier find ich echt genial einfach performant und bei bedarf auch redundant, man kann dabei so ziemlich alles entweder an einen domainadmin oder an den user selbst deligieren
falls du relay server meinst das hab ich schlicht mit webmin geloest weil am einfachsten
und bei mehreren domains gibts schlicht auch einfach grenzen welche policies man benutzt, das laesst sich dann eigentlich nur noch mit verschiedenen instanzen machen, aber finde ich als zu overloaded und ich habs eigentlich auch noch nicht wirklich benoetigt.
Christian
postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
* Christian Bricart christian@bricart.de wrote:
Hier laufen im moment insgesamt 10 proxymap-Prozesse und jeder steht im top mit CPU-Werten zwischen 10% und 20% (das ist ne 2-vCPU-VM auf ESX)
Wenn Du da einen Trace drauf machst, siehst Du?
Ciao Stefan
Zitat von Christian Bricart christian@bricart.de:
Tach zusammen,
erstmal zum Verständnis:
ist es korrekt, dass es jeweils genau einen proxymap Prozess für jede in der main.cf referenenzierten "proxy:blubber:...." gibt? d.h Änderungen in der master.cf unter MaxProcs für proxy werden ignoriert..?
Und jetzt zur eigentlichen Frage:
Hier laufen im moment insgesamt 10 proxymap-Prozesse und jeder steht im top mit CPU-Werten zwischen 10% und 20% (das ist ne 2-vCPU-VM auf ESX)
irgendwie ist mein System also zu 90% mit proxymap-Prozessen beschäftigt - und das alles auf CPU... was zum Geier muss der abfragende Client bei ner SQL-Abfrage denn so gross "rechnen".. das macht doch der DB-Server der gefragt wird..
Proxymap sollte nahezu keinerlei CPU-Zeit verbrauchen da er nur als einfacher Multiplexer für die anderen Prozesse arbeitet. Allerdings gibt es Probleme wenn die Datenbank/LDAP Abfragen zu lange dauern :
The proxymap(8) server provides service to multiple clients, and must therefore not be used for tables that have high-latency lookups.
In diesem Falle die Abfragen beschleunigen (Index o.ä. verwenden) oder die Anzahl der Proxymap Server hochsetzten bzw. die Anzahl der Clientprozesse senken. Bei sehr vielen Abfragen pro Zeiteinheit den "max_use" parameter zu erhöhen um die Anzahl der Forks zu senken.
Gruß
Andreas
MailingListe wrote:
Zitat von Christian Bricart christian@bricart.de:
Tach zusammen,
erstmal zum Verständnis:
ist es korrekt, dass es jeweils genau einen proxymap Prozess für jede in der main.cf referenenzierten "proxy:blubber:...." gibt? d.h Änderungen in der master.cf unter MaxProcs für proxy werden ignoriert..?
Und jetzt zur eigentlichen Frage:
Hier laufen im moment insgesamt 10 proxymap-Prozesse und jeder steht im top mit CPU-Werten zwischen 10% und 20% (das ist ne 2-vCPU-VM auf ESX)
irgendwie ist mein System also zu 90% mit proxymap-Prozessen beschäftigt
und das alles auf CPU... was zum Geier muss der abfragende Client bei ner SQL-Abfrage denn so gross "rechnen".. das macht doch der DB-Server der gefragt wird..
Proxymap sollte nahezu keinerlei CPU-Zeit verbrauchen da er nur als einfacher Multiplexer für die anderen Prozesse arbeitet. Allerdings gibt es Probleme wenn die Datenbank/LDAP Abfragen zu lange dauern :
The proxymap(8) server provides service to multiple clients, and must therefore not be used for tables that have high-latency lookups.
wie ich in dem anderen Thread schon schrieb hab ich keine Query über 3ms auf der DB... oder ist das etwa schon "high-latency"..? ;-)
In diesem Falle die Abfragen beschleunigen (Index o.ä. verwenden) oder die Anzahl der Proxymap Server hochsetzten bzw. die Anzahl der Clientprozesse senken. Bei sehr vielen Abfragen pro Zeiteinheit den "max_use" parameter zu erhöhen um die Anzahl der Forks zu senken.
in der master.cf steht in der proxy-Zeile bei max_use: "-" das heisst doch, dass die max Anzahl von der eingestellten max_use bei smtpd beschränkt wird, oder?
Christian
Zitat von Christian Bricart christian@bricart.de:
MailingListe wrote:
Zitat von Christian Bricart christian@bricart.de:
Tach zusammen,
erstmal zum Verständnis:
ist es korrekt, dass es jeweils genau einen proxymap Prozess für jede in der main.cf referenenzierten "proxy:blubber:...." gibt? d.h Änderungen in der master.cf unter MaxProcs für proxy werden ignoriert..?
Und jetzt zur eigentlichen Frage:
Hier laufen im moment insgesamt 10 proxymap-Prozesse und jeder steht im top mit CPU-Werten zwischen 10% und 20% (das ist ne 2-vCPU-VM auf ESX)
irgendwie ist mein System also zu 90% mit proxymap-Prozessen beschäftigt
und das alles auf CPU... was zum Geier muss der abfragende Client bei ner SQL-Abfrage denn so gross "rechnen".. das macht doch der DB-Server der gefragt wird..
Proxymap sollte nahezu keinerlei CPU-Zeit verbrauchen da er nur als einfacher Multiplexer für die anderen Prozesse arbeitet. Allerdings gibt es Probleme wenn die Datenbank/LDAP Abfragen zu lange dauern :
The proxymap(8) server provides service to multiple clients, and must therefore not be used for tables that have high-latency lookups.wie ich in dem anderen Thread schon schrieb hab ich keine Query über 3ms auf der DB... oder ist das etwa schon "high-latency"..? ;-)
Es kommt drauf an ....
Wenn z.B. 300 smtpd jeweils 5 lookups pro Mail-Transaktion benötigen und es stehen nur 10 proxymap zur Verfügung ergibt das
300/10 * 5 * 3ms = 450 ms
also ca. 0,5 sec pro Mailtransaktion nur für die Lookups.
Interessant wären folgende Fragen : - Anzahl der Datenbankanfragen pro Mailtransaktion - Dauer der längsten DB-Anfrage unter Belastung und über das Netzwerk - Anzahl der aktiven "smtpd" und anderer relevanter Prozesse (cleanup etc.)
Der erste Ansatz sollte immer sein die Anzahl der Lookups pro Mailtransaktion klein zu halten, der zweite diese Abfragen so effizient wie möglich zu gestalten und dann das ganze über ein passende Anzahl an "proxymap" Servern zu verteilen.
In diesem Falle die Abfragen beschleunigen (Index o.ä. verwenden) oder die Anzahl der Proxymap Server hochsetzten bzw. die Anzahl der Clientprozesse senken. Bei sehr vielen Abfragen pro Zeiteinheit den "max_use" parameter zu erhöhen um die Anzahl der Forks zu senken.
in der master.cf steht in der proxy-Zeile bei max_use: "-" das heisst doch, dass die max Anzahl von der eingestellten max_use bei smtpd beschränkt wird, oder?
"max_use" wird in main.cf definiert... Der default ist 100
Gruß
Andreas
participants (4)
-
Christian Bricart -
MailingListe -
Robert Schetterer -
Stefan Förster