So I've managed to set up qmail as purely a delivery agent for mailing
list mail, as opposed to the only MTA on the system. It'll probably be
handling ~150K deliveries a day (on a good day), as a P5-150, 96M ram,
BSDI 2.1 machine. I figure once I know my way around this setup
transferring to full use of qmail will be a manageable task.
Because I have a lot of traffic and a lot of deliveries to distant lands
and slow connections, I've set concurrencyremote to 100. When I was using
sendmail I'd average 100-150 simultaneous connections during the day so
this made sense to me.
The main problem I have with my setup is that when a message comes in for
a 500-person list, and qmail-remotes are fired up to handle the traffic,
the jump in number of processes in such a short time (within 3 seconds)
swamps my machine. It'll be idling there around 10 -remotes and then fork
off another 90. This is a pretty big performance hit - and since they're
all started at once they hit DNS and then the network at the same time.
So for a good 10 seconds the machine is literally at 100% utilization.
This is bad only so far as this machine is performing lots of other tasks
(web server, telnet server, lots of DNS primary hosting) and getting
swamped for 10 seconds every 5 minutes is not a Good Thing. Though some
will of course beg to differ.
One way to ameliorate this swamping is to set limits on the speed at which
qmail-remotes may be launched. If it could be limited to 5 per second,
say, or 3, the process initialization, DNS, and network hits would be
staggered.
I was going to give this a try by putting a simple usleep() command
somewhere in qmail-send, but I was wondering what other folks thought.
Surely if I turned down concurrencyremote to 20 there would be less
impact, but then mail would be delivered more slowly too.
Down the road Dan (or whomever else contributes) may want to think about
what we did for Apache, where a pool of servers are constantly running,
adjusting themselves in number depending on the number of spare resources
they have. Web traffic is a little more constant than email traffic is
so that might not be the right model, but who knows.
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@hyperreal.com http://www.apache.org http://www.organic.com/jobs
list mail, as opposed to the only MTA on the system. It'll probably be
handling ~150K deliveries a day (on a good day), as a P5-150, 96M ram,
BSDI 2.1 machine. I figure once I know my way around this setup
transferring to full use of qmail will be a manageable task.
Because I have a lot of traffic and a lot of deliveries to distant lands
and slow connections, I've set concurrencyremote to 100. When I was using
sendmail I'd average 100-150 simultaneous connections during the day so
this made sense to me.
The main problem I have with my setup is that when a message comes in for
a 500-person list, and qmail-remotes are fired up to handle the traffic,
the jump in number of processes in such a short time (within 3 seconds)
swamps my machine. It'll be idling there around 10 -remotes and then fork
off another 90. This is a pretty big performance hit - and since they're
all started at once they hit DNS and then the network at the same time.
So for a good 10 seconds the machine is literally at 100% utilization.
This is bad only so far as this machine is performing lots of other tasks
(web server, telnet server, lots of DNS primary hosting) and getting
swamped for 10 seconds every 5 minutes is not a Good Thing. Though some
will of course beg to differ.
One way to ameliorate this swamping is to set limits on the speed at which
qmail-remotes may be launched. If it could be limited to 5 per second,
say, or 3, the process initialization, DNS, and network hits would be
staggered.
I was going to give this a try by putting a simple usleep() command
somewhere in qmail-send, but I was wondering what other folks thought.
Surely if I turned down concurrencyremote to 20 there would be less
impact, but then mail would be delivered more slowly too.
Down the road Dan (or whomever else contributes) may want to think about
what we did for Apache, where a pool of servers are constantly running,
adjusting themselves in number depending on the number of spare resources
they have. Web traffic is a little more constant than email traffic is
so that might not be the right model, but who knows.
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@hyperreal.com http://www.apache.org http://www.organic.com/jobs