Brad Nicholson wrote:
> On Thu, 2007-01-25 at 08:59 +0100, Brinon Philippe wrote:
>   
>> 3- Which parameters is it possible to change in order to minimize the
>> activity of the master and slaves?
>>     
>
> Hmm, I'm not sure about this one, but I wonder about setting forward='f'
> on the subscribers that will never need to be promoted to master.  They
> will stop collecting sl_log data - in theory that should reduce your
> activity.
>   
That would indeed be one effect that would diminish the needful amount
of DB work.  However, I have to point out that this does not explain why
CPU activity on the *master* node would be high; this particular change
should only affect behaviour on subscribers...

It looks to me like the situation/problem Brinon Philippe is observing
is that there is way more work being done processing events and event
confirmations than was expected. 

This steps us back to an old debate about the issue that every node has
to process confirmation of receipt of every event that goes to every
other node.

We always knew there was a quadratic (or possibly more) increase in
communications activity as the number of nodes increases (e.g. - number
of messages increases based on O(n^2), where n is the number of nodes),
so when you have 11 nodes, that is expected to have on the order of 121
times as much communications work as when you have 1.

It may be that when there are 11 nodes not doing much actual
replication, the communications work starts to very much outweigh the
amount of "actual replication effort."

There are two ways I can see of cutting down on that:

1.  In Slony-I 1.2, confirmations are processed somewhat less often, and
notifications are NOT sent out to handle this.

Thus, I expect that version 1.2 will "play better" than 1.1, in general
terms.

2.  If the nodes are richly interconnected, they'll all be processing
all of each others' events all the time.

On the other hand, if you cut down on the number of paths (e.g. - number
of connections in sl_path), then events will propagate a bit less
directly, slons will open fewer connections to listen to other nodes,
and I'd expect the flurry of DB activity to be somewhat less.