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(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-directory-users