After installation and test of the version 1.2.6, I noted a strong decrease of the CPU activity on the master node and a lighter decrease of the CPU activity on each of the 10 slave nodes.
Consequently, there is no need now to try to limit the communication activity. Thanks again for your pieces of advice. Philippe -----Message d'origine----- De : Christopher Browne [mailto:[EMAIL PROTECTED] Envoyé : jeudi 25 janvier 2007 18:37 À : Brad Nicholson Cc : Brinon Philippe; [email protected] Objet : Re: [Slony1-general] How to minimize the CPU activity on a SLONY master node? 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. ********************************************************************************************** Le contenu de cet e-mail et de ses pièces jointes est destiné à l'usage exclusif du (des) destinataire(s) expressément désigné(s) comme tel(s). En cas de réception de cet e-mail par erreur, le signaler à son expéditeur et ne pas en divulguer le contenu. L'absence de virus a été vérifié à l'émission du message. Il convient néanmoins de vérifier l'absence de corruption à sa réception. The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email in error please notify the system manager or the sender immediately and do not disclose the contents to anyone or make copies. eSafe scanned this email for viruses, vandals and malicious content. ********************************************************************************************** _______________________________________________ Slony1-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/slony1-general
