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