Victor.Duchovnimorganstanley.com
Date: Fri Jun 13 2003 - 10:59:19 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Fri, 13 Jun 2003, Leandro Santi wrote:

> > > % 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
>
> Actually, the last proxymap instance has now 1 day of existance (that ps
> snapshot was taken about 12:10 :-). So, the real numbers are:
>
> first proxymap : ~ 1.07 % CPU
> second proxymap: ~ 1.16 % CPU
> third proxymap : ~ 2.02 % CPU
>
> So it seems that the work is in fact being spread evenly (because the
> first two are born at about the same time and have comparable cpu usage
> rates, but the last one can't be compared against the other two because
> it has had lived much longer hence has been working at rush hour).
>

What happened was that once the load spiked high enough to generate
additional proxymap instances, the client requests are spread relatively
evenly over the proxymap daemon population. None of them exit, because
even after the load declines, each accepts some new connections during the
lifetime of any given connection (and loses an equal number of old
connection).

If you apply my experimental multi-server lifetime patch from Ralf's site,
you should see the proxymap population decrease back to 1 some time after
load spikes.

Under typical conditions the query load from Postfix should be light
compared to the cost of I/O queueing the messages and network latency, and
the database is not stressed. This changes under dictionary attack.

If the dictionary attack is via a single SMTP session (often it is not,
but it can be), then all the queries go to one proxymap instance, so only
one database slows down. This is perhaps a good thing, as the high latency
of the attacked database (if noticeable) will steer connections to other
proxymap servers which are querying databases that are not under attack.
So long as the backend selection is random, the system should be resient.

--
        Viktor.

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]