|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
Re: (patch) Enhanced MySQL driver
From: Wietse Venema (wietse
porcupine.org)
Date: Fri Jun 13 2003 - 10:29:59 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Leandro Santi:
> On Wed, Jun 11, 2003, Victor.Duchovni
morganstanley.com wrote:
> > Wietse's point is that lack of load-balancing is not important unless it
> > leads to query latency. Query latency will cause the proxymap service to
> > be busy and therefor more instances will be spawned. If 5 proxymap
> > instances are all it takes to handle the load, the load-balancing is
> > adequate.
> >
> > So it is unlikely that assymetric loading will make any one of the MySQL
> > servers so tardy as to be unusable for other applications, there may also
> > be connection setup costs in MySQL that you are not measuring.
> >
> > Try it with statistical load balancing first, and if evidence emerges that
> > this is not good enough, solve the more complex problem later.
>
> Well, I've been running the proxymap for a few days, and it seems that one
> of its instances is getting most part of the work:
>
> % ps -f -p "`pgrep proxymap`"
> UID PID PPID C STIME TTY TIME CMD
> postfix 21272 12361 1 08:55:33 ? 2:04 proxymap -t unix -u
> postfix 151 12361 1 07:20:31 ? 3:22 proxymap -t unix -u
> postfix 16736 12361 1 12:15:12 ? 29:03 proxymap -t unix -u
>
> I already understood that, when lots of work requests arrive, the Postfix
> daemons will "naturally" discover and connect to the less active ones,
> because of its (ingenious) design. However, I think that its a desirable
> feature (second of third order if you like :) to spread the load evenly not
> just when the whole (ie Postfix + backend) system is somewhat near saturation
> but when working at cruise speed, too.
The genius here was letting the OS scheduler do the work for Postfix
(instead of fighting against it).
What you see is that one proxymap process is sufficient most of
the time. The other ones kick in when that process gets busy.
Note also that trivial-rewrite will keep an almost persistent
connection. If you like, shorten ipc_idle to a few seconds and see
what happens.
Wietse
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]