Bug#731795: failures under load with slapd in wheezy
dpkg -l slapd ii slapd2.4.39-1 amd64 OpenLDAP server (slapd) Test script, run from another system: for i in `seq 2048`; do ldapsearch -x -H ldaps://ldapm1.test.realityfailure.org -b ou=people,dc=test,dc=realityfailure,dc=org done 21 | grep -i sasl I've bumped it up to 4096, but am currently hitting the physical limits of my virtuals in testing. In other words, I believe an update to 2.4.39 resolved the specific issue I encountered. On 08/06/2014 01:01 AM, Ryan Tandy wrote: tags 731795 + moreinfo thanks Hi John, I've tried a couple of times now to reproduce this bug in wheezy, with no luck. I've tried forking many ldapsearch instances like you suggested, as well as the slapd-mtread tool from the test suite, and the only failures I get are when slapd hits the open files limit (even with that increased to 65536 or higher). Is it possible for you to try the 2.4.39 package from testing and confirm whether the problem is solved? Otherwise, any more information you can provide about a scenario that reproduces this would be helpful. thanks, Ryan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731795: failures under load with slapd in wheezy
Perhaps some of this background information will be useful: We did not see this issue in slapd 2.4.23-7.3, in squeeze. The number of unique entries in the LDAP database do not appear to affect where it starts dropping connections, as we've tested with 2 to over 500 unique accounts. The number of entries searched for do not seem to affect where connections start failing, as tests were run on one particular DN, and on up to 15 unique DNs. This can be reproduced through a simple while loop in shell, using the ldapsearch command line tools. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731795: failures under load with slapd in wheezy
Package: slapd Version: 2.4.31-1+nmu2 Placing the slapd server under load, at somewhere between 512 and 1024 simultaneous connections (using TLS, may be higher unencrypted), you will end up see variations of: ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) Under simple tests, I've seen these occur for anywhere between 5 and 50% of the connection attempts. I have been able to replicate this on systems ranging from a VM with 256M of ram to an 8GB physical server to a 24GB 12 CPU system (2 physical, 6 cores each), and it all fails in the same range of connections. Recommendation: Upgrade to slapd-2.4.38 in jessie and wheezy-backports. According to the openldap changelogs (http://www.openldap.org/software/release/changes.html), the following fix was included in openldap 2.4.32: Fixed slapd-bdb/hdb cache hang under high load (ITS#7222) I downloaded and compiled openldap 2.4.38 on a 256MB VM system, using the same configuration options Debian uses. Under current tests, it has survived over 16k connections without any errors. This is a factor of 4, and still going. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
