[Freeipa-users] Replication time and relation to cache size

[thierry bordaz]

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 <aalam at paperlesspost.com
>> <mailto:aalam at 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.