Prev: proxymap(8), number of connections, detecting altered tables
Next: address verification, smtpd_mumble_error_limit,smtpd_client_event_limit_exceptions
From: Ralf Hildebrandt on 15 Jul 2010 09:37 * Stefan Foerster <cite+postfix-users(a)incertum.net>: > While I agree that it is totally obvious that table are re-read as > soon as a new proxymap(8) process is spawned, on a resonably busy > system, this won't happen too often. So getting a definitive answer on > that one would still be helpful. Has this been answered? It also affects me, so I'd like to know :) -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebrandt(a)charite.de | http://www.charite.de
From: Wietse Venema on 15 Jul 2010 09:52 Ralf Hildebrandt: > * Stefan Foerster <cite+postfix-users(a)incertum.net>: > > > While I agree that it is totally obvious that table are re-read as > > soon as a new proxymap(8) process is spawned, on a resonably busy > > system, this won't happen too often. So getting a definitive answer on > > that one would still be helpful. > > Has this been answered? It also affects me, so I'd like to know :) There is no definitive answer. The strategy of how to detect changes is evolving over time, and some tables (pcre, regexp, cidr) do not implement change detection at this time. If you really must force a change, use "postfix reload". Wietse
From: Victor Duchovni on 15 Jul 2010 14:20 On Thu, Jul 15, 2010 at 09:52:35AM -0400, Wietse Venema wrote: > Ralf Hildebrandt: > > * Stefan Foerster <cite+postfix-users(a)incertum.net>: > > > > > While I agree that it is totally obvious that table are re-read as > > > soon as a new proxymap(8) process is spawned, on a resonably busy > > > system, this won't happen too often. So getting a definitive answer on > > > that one would still be helpful. > > > > Has this been answered? It also affects me, so I'd like to know :) > > There is no definitive answer. The strategy of how to detect changes > is evolving over time, and some tables (pcre, regexp, cidr) do not > implement change detection at this time. > > If you really must force a change, use "postfix reload". Also, only use proxymap for IPC based tables (ldap, mysql, pgsql, tcp, ...), do not use proxymap for indexed files, cidr tables, pcre/regexp tables, .... -- Viktor.
From: Wietse Venema on 15 Jul 2010 14:31 Victor Duchovni: > On Thu, Jul 15, 2010 at 09:52:35AM -0400, Wietse Venema wrote: > > > Ralf Hildebrandt: > > > * Stefan Foerster <cite+postfix-users(a)incertum.net>: > > > > > > > While I agree that it is totally obvious that table are re-read as > > > > soon as a new proxymap(8) process is spawned, on a resonably busy > > > > system, this won't happen too often. So getting a definitive answer on > > > > that one would still be helpful. > > > > > > Has this been answered? It also affects me, so I'd like to know :) > > > > There is no definitive answer. The strategy of how to detect changes > > is evolving over time, and some tables (pcre, regexp, cidr) do not > > implement change detection at this time. > > > > If you really must force a change, use "postfix reload". > > Also, only use proxymap for IPC based tables (ldap, mysql, pgsql, tcp, ...), > do not use proxymap for indexed files, cidr tables, pcre/regexp tables, .... It depends on what the trade-offs are. I know of one user with very large cidr tables - sacrificing performance to avoid running out of physical memory. Wietse
From: Victor Duchovni on 15 Jul 2010 14:59
On Thu, Jul 15, 2010 at 02:31:36PM -0400, Wietse Venema wrote: > > Also, only use proxymap for IPC based tables (ldap, mysql, pgsql, tcp, ...), > > do not use proxymap for indexed files, cidr tables, pcre/regexp tables, .... > > It depends on what the trade-offs are. I know of one user with > very large cidr tables - sacrificing performance to avoid running > out of physical memory. One might suggest that CIDR is not a good fit for this even if stored just once, an IPC based server that walks trees rather than lists would be far more suitable... -- Viktor. |