On 07/07/2016 03:47 PM, Martin Kosek wrote:
On 06/21/2016 05:19 PM, Ash Alam wrote:
anyone have any thoughts on this?

Thank You

On Fri, Jun 10, 2016 at 2:59 PM, Ash Alam <aa...@paperlesspost.com
<mailto:aa...@paperlesspost.com>> wrote:

     Hello

     I have been going through the lists but i have not found the answer i am
     looking for. I am seeing few issues for which i am looking for some
     clarification.

     1. What is the relationship between replication time and cache size?

     - I am noticing that it's taking up to 5 minutes for some things to
     replication when change is made on one node and there are two additional
     masters. The ipa nodes are all virtual machines within the same cluster.
Hi Ash,

There is no direct relation between replication time (latency) and the cache size. But it is possible that with a greater cache, processing of the replicated updates will be faster. Now many parameters can explain latency (power of the boxes, masters competing for exclusive access to a replica, many updates filtered before sending one...)
The latency was greatly reduced since 1.3.5.4.



     - WARNING: changelog: entry cache size 2097152B is less than db size
     116154368B; We recommend to increase the entry cache size 
nsslapd-cachememsize.

This warning is generic for all suffixes. Now changelog is a special suffix and a small entry cache should not create any issue.

     - I don't understand the cache size. Would't increasing it cause the same
     issue when we hit the new limit?
To process an entry (search/update), the entry is loaded in memory into a cache. The entry remains in the cache until it needs space to load others entries. The cache is always full and this does not create any issue. If you have a small database and all the entries can fit in the cache, it worth testing with a large cache.
Otherwise a cache of [100-200] Mb is most of the time a good tuning.

     - connection - conn=3779 fd=175 Incoming BER Element was 3 bytes, max
     allowable is 209715200 bytes. Change the nsslapd-maxbersize attribute in
     cn=config to increase.
It comes from a failure (overflow) to decode a ber (ber_get_next). The maxbersize is 200Mb that looks large enough to handle any req. Is it a frequent issue ? Is there any network issue ?

     2. Is there a definitive solution to this error? This seems to pop up every
     so often.

     - NSMMReplicationPlugin - agmt="cn=meToipa009.pp" (ipa009:389): Warning:
     Attempting to release replica, but unable to receive endReplication 
extended
This message comes from a replica agreement that is responsible to replicate updates to an other DS instance (ipa0009). When this replica agreement has no more update to send, it send an 'endReplication' and expects a response (from ipa0009). Here for some reason, ipa0009 is not responding. You may check the error logs.

Hi Ash,

I see no reply, let me try and hook Thierry/Ludwig, they should know more.

Martin

P.S. sorry for the delay, most of FreeIPA core developers were focused on
getting FreeIPA 4.4 out of the door.

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Reply via email to