On 11/05/2014 12:54 PM, Ivanov Andrey (M.) wrote:


* if the virtual machine has only one CPU. Adding a second CPU increases the number of transferred entries before the initialization gets stuck. So it may me some thread/transaction  contention or deadlock.
* if the replication agreement uses SSL(port 636) or TLS(port389). Using port 389 with LDAP protocol instead of TLS/SSL increases the number of transferred entries before the initialization gets stuck. Sometimes the initialization even ends successfully in this case.
* decreasing nsslapd-db-checkpoint-interval (say, to 5 seconds) also gets the problem worse
This indicates the issue is in the BDB?
Don't know. My hypotheses are :
* using plugin transactions compared to 1.2.10.x
* bdb version? but even with compat-db-47 and 1.2.10 the problem still happens on CentOS7, though much less frequently. It never happens with 1.2.10 with rpm bdb on CentOS5.
* change from  mozilla ldap libraries to openldap libraries?

seems to be some sort of thread or transaction contention that is reduced when i add CPUs/increase checkpoint interval. It really looks like the master server just does not send entries any more at some moment... SSL/TLS slows the things down so less entries are sent before everything gets stuck...

I'll get back with more information (stacktraces) tomorrrow.
Another version :
insufficient entropy generation speed for TLS/SSL total update (/dev/urandom vs blocking /dev/random), especially in VMs??


it is possible the VM system is running out of entropy, and apps to experience long delays, to verify:
cat /proc/sys/kernel/random/entropy_avail

one way to fix this is to use and run the haveged service on the KVM guest, that can be downloaded from EPEL

it can also depends on the VM configuration, for example if using KVM and libvirt (recent version), use the KVM host entropy is with a configuration similar to this:
  <rng model='virtio'>
     <backend model='random'>/dev/random</backend>
     <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
   </rng>
</devices>
without that config, my test RHEL 7 KVM guest has quite a low entropy.
and the entropy will depends on the cpu characteristics.



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users