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?
On Fri, Jun 10, 2016 at 2:59 PM, Ash Alam <aa...@paperlesspost.com
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
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.
There is no direct relation between replication time (latency) and the
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 22.214.171.124.
- WARNING: changelog: entry cache size 2097152B is less than db size
116154368B; We recommend to increase the entry cache size
This warning is generic for all suffixes. Now changelog is a special
suffix and a small entry cache should not create any issue.
To process an entry (search/update), the entry is loaded in memory into
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.
- I don't understand the cache size. Would't increasing it cause the same
issue when we hit the new limit?
Otherwise a cache of [100-200] Mb is most of the time a good tuning.
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 ?
- 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.
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.
2. Is there a definitive solution to this error? This seems to pop up every
- NSMMReplicationPlugin - agmt="cn=meToipa009.pp" (ipa009:389): Warning:
Attempting to release replica, but unable to receive endReplication
I see no reply, let me try and hook Thierry/Ludwig, they should know more.
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:
Go to http://freeipa.org for more info on the project