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 <[email protected]
<mailto:[email protected]>> 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
