[Fedora-directory-users] multi-master limit

[Rich Megginson]

Enrico M. V. Fasanelli wrote:
>
> Dear Rich,
>
> can you explain with some numbers on that?
Not really.  I don't have any exact numbers or formulae that you can 
plug in various parameters such as OS, RAM, CPUs, etc.
>
> How much RAM I need per each separate thread? How many replication 
> agreement in a server equipped with 2, 4, 8, 16 GB RAM?
>
> How the avg. update rate influence these numbers? And the max update 
> rate?
In general, the higher the average update rate, the harder the server is 
going to have to work to send out updates to all replicas.  And a very 
high update rate for a short period of time may spike the RAM and/or CPU 
usage.
>
> 30 replication agreement per server is a medium value? large? huge? 
> Too much? Out of any hardware configuration?
I don't really have a good answer for any of these questions.  I do know 
that at some point you are going to see a drop off in performance due to 
thread contention.  Adding more RAM and CPUs will mitigate this drop.
>
> Thank in advance.
>
> Ciao,
>     Enrico
>
>
> Rich Megginson wrote:
>
>> Also important to keep in mind is your update rate - avg. updates per 
>> minute, max. updates per minute.
>
> [...snips...]
>
>> In Fedora DS, replication is supplier initiated, and will update as 
>> soon as possible by default.  That is, as soon as the supplier 
>> receives the change, it will send it to the consumer.  There are also 
>> programmatic ways to do it, but you usually don't need to.
>
> [...snips...]
>
>>> That means 4 is the highest number of masters we've tested
>>> exhaustively.  The protocol supports up to 2^32-2 masters, but you will
>>> usually hit a practical limit in the number of replication 
>>> agreements.  Each repl. agreement runs a separate thread, so you 
>>> will usually be
>>> constrained by resources - available RAM, processors, etc.
>
> [...snips...]
>
>
>
> ------------------------------------------------------------------------
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20071205/877fcc5c/attachment.bin>