multi-master limit

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 


[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux