proxymap(8), number of connections, detecting altered tables
in [Postfix]
|
Prev: proxymap(8), number of connections, detecting altered tables
Next: address verification, smtpd_mumble_error_limit,smtpd_client_event_limit_exceptions
From: Stefan Foerster on 20 Jun 2010 07:28 Two questions regarding proxymap: 1. Is a single proxymap(8) process able to handle multiple lookup tables? I.e., taking the example from the manpage, modifying it to mysql = proxy:mysql:/etc/postfix/ virtual_alias_maps =${mysql}virtual_alias_maps.cf virtual_alias_domains = ${mysql}virtual_alias_domains.cf and furthermore assuming a limit of 40 proxymap(8) processes defined in master.cf, will this result in 40 or 80 connections to the database? 2. Typically, changes in CIDR, PCRE or RegExp tables are not detected immediately, which is not a problem for short lived processes like smtpd(8). If those tables are provided by means of proxymap(8) (to e.g. save memory on very large CIDR tables), will the tables be re-read as soon as a newly spawned smtpd(8) makes a connection to proxymap(8) or is it necessary to reload Postfix? Stefan
From: Stefan Foerster on 20 Jun 2010 09:16 * Stan Hoeppner <stan(a)hardwarefreak.com>: > Stefan Foerster put forth on 6/20/2010 5:16 AM: > > and furthermore assuming a limit of 40 proxymap(8) processes defined > > in master.cf, will this result in 40 or 80 connections to the > > database? > > I have no idea on this one. The whole point of proxymap is to have one > process reading all maps to cut down on the memory footprint of multiple > concurrent smtpd processes. Why anyone would want 40 proxymap processes is > beyond me. Doing this seems counterproductive. The default process limit for proxymap(8) if you didn't change master.cf is $default_process_limit which seems to default to 100. So my question is, indeed, very valid, I guess :-) > > 2. Typically, changes in CIDR, PCRE or RegExp tables are not detected > > immediately, which is not a problem for short lived processes like > > smtpd(8). If those tables are provided by means of proxymap(8) (to > > e.g. save memory on very large CIDR tables), will the tables be > > re-read as soon as a newly spawned smtpd(8) makes a connection to > > proxymap(8) or is it necessary to reload Postfix? > > I believe this is controlled by max_idle and ipc_idle. When the timer > expires, the proxymap process is killed. The next process that needs one of > the tables causes the proxymap process launch. At this point the tables are > read. If you need an update to be read before the process expires, you would > have to do a reload. 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. Stefan
From: Wietse Venema on 20 Jun 2010 09:24 Stefan Foerster: > Two questions regarding proxymap: > > 1. Is a single proxymap(8) process able to handle multiple lookup > tables? I.e., taking the example from the manpage, modifying it to > > mysql = proxy:mysql:/etc/postfix/ > virtual_alias_maps =${mysql}virtual_alias_maps.cf > virtual_alias_domains = ${mysql}virtual_alias_domains.cf > > and furthermore assuming a limit of 40 proxymap(8) processes defined > in master.cf, will this result in 40 or 80 connections to the > database? This depends on the query load. When a client needs proxymap service it is either helped by an existing proxymap process that is idle, or else it is helped by a new proxymap process. In the first case it will share the table with other proxymap clients. > 2. Typically, changes in CIDR, PCRE or RegExp tables are not detected > immediately, which is not a problem for short lived processes like > smtpd(8). If those tables are provided by means of proxymap(8) (to > e.g. save memory on very large CIDR tables), will the tables be > re-read as soon as a newly spawned smtpd(8) makes a connection to > proxymap(8) or is it necessary to reload Postfix? CIDR, PCRE or RegExp tables have no change detection mechanism. That requires keeping the file handle open, which seems wasteful. Most proxymap daemons will retire after a thousand seconds or so but it may take longer on busy servers. This may be sped up by reducing main.cf:ipc_ttl to 100s or so. Wietse
From: Stefan Foerster on 20 Jun 2010 10:38 * Wietse Venema <wietse(a)porcupine.org>: > Stefan Foerster: > > Two questions regarding proxymap: > > > > 1. Is a single proxymap(8) process able to handle multiple lookup > > tables? I.e., taking the example from the manpage, modifying it to > > > > mysql = proxy:mysql:/etc/postfix/ > > virtual_alias_maps =${mysql}virtual_alias_maps.cf > > virtual_alias_domains = ${mysql}virtual_alias_domains.cf > > > > and furthermore assuming a limit of 40 proxymap(8) processes defined > > in master.cf, will this result in 40 or 80 connections to the > > database? > > This depends on the query load. When a client needs proxymap service > it is either helped by an existing proxymap process that is idle, > or else it is helped by a new proxymap process. In the first case > it will share the table with other proxymap clients. As a follow-up: If a clients needs to be served by a new proxymap process but none are available, what happens? Stefan
From: Wietse Venema on 20 Jun 2010 10:54
Stefan Foerster: > > This depends on the query load. When a client needs proxymap service > > it is either helped by an existing proxymap process that is idle, > > or else it is helped by a new proxymap process. In the first case > > it will share the table with other proxymap clients. > > As a follow-up: If a clients needs to be served by a new proxymap > process but none are available, what happens? The proxymap client waits. Wietse |