Bug#311491: slapd stops functioning almost completely if a CPU consuming process runs at the same time
On Thu, 2 Jun 2005, Torsten Landschoff wrote: Hi Ulrich, [...] That's unlikely to happen. And, BTW: I guess this bug is also a problem with the current linux kernel. Somebody on linux-kernel pointed out that he got 10% CPU usage by having 3 processes talk to each other in a ring inside an endless loop. For some reason the scheduler thinks that no process is ready to run. Hmm, possibly there is a problem with the scheduler itself. However, as I have written, the problem didn't show up with woody and a 2.6.7 kernel. I have applied the tag "sarge" because of this - why was it removed? I noticed that in all operating system configurations where the problem arises (that is, when using sarge), the slapd fails to spawn additional threads when a query is made (which it does when using woody). Maybe here something is wrong? What does top say about your CPU usage? I don't see anything conspicuous - if I start a CPU consuming process, it gets 99%, and slapd almost doesn't show up. Talking about severities: We will not delay sarge because slapd has a performance problem for one user. I am respecting your decision, of course, and I understand completely that time is short now. However, though I have not tested everything, the bug really doesn't seem to be specific to any aspect of our slapd configuration, which is simple and standard. (Please tell me if I you think that the problem doesn't arise in every slapd configuration.) And it is not just a performance problem - as I have written, the slapd needs more than 2000 x the amount of time it would need without a concurrent process. For all practical purposes: It just hangs. I didn't exaggerate to make it seem more important. Don't just believe me: This can be reproduced very easily. Best regards Ulrich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311491: slapd stops functioning almost completely if a CPU consuming process runs at the same time
| Talking about severities: We will not delay sarge because slapd has a | performance problem for one user.=20 I guess this is a disputable decision. This makes sarge unusable for an ldap server. Our whole ldap system (a few hundred users involved) was repeatedly blocked by this bug, because of minor cpu consuming processes on that server caused by some erroneously terminated login processes to that server. We had to switch to freebsd for the ldap server because of this. Please reconsider. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311491: slapd stops functioning almost completely if a CPU consuming process runs at the same time
Hi Ulrich, On Wed, Jun 01, 2005 at 07:10:08PM +0200, Ulrich Hermisson wrote: > I would be very happy with either kind of solution. Since the package, in > its current state, cannot be used by us and, as I presume, many other > people, it would be a big improvement if the problem were solved before > the release of Debian Sarge. I will try to continue to help with this. That's unlikely to happen. And, BTW: I guess this bug is also a problem with the current linux kernel. Somebody on linux-kernel pointed out that he got 10% CPU usage by having 3 processes talk to each other in a ring inside an endless loop. For some reason the scheduler thinks that no process is ready to run. What does top say about your CPU usage? Talking about severities: We will not delay sarge because slapd has a performance problem for one user. Greetings Torsten signature.asc Description: Digital signature
Bug#311491: slapd stops functioning almost completely if a CPU consuming process runs at the same time
On Wed, 1 Jun 2005, Torsten Landschoff wrote: On Wed, Jun 01, 2005 at 12:16:05PM +0200, Ulrich Hermisson wrote: from www.openldap.org (compiled with "--enable-crypt"). Only when I compile with the configure option "--with-threads=no", everything is ok, but the slurpd needs threads. With threads, also the test 17 performed by "make test" fails if a CPU consuming process is running in parallel. I have reproduced the bug on the following architectures/kernel versions (always with Debian Sarge): Opteron/2.6.7, Opteron/2.6.11, Athlon/2.6.8, Pentium 4/2.6.8. With Debian Woody on Pentium 4/2.6.7, everything works, also with FreeBSD. Known problem. I'd guess the reason is that OpenLDAP is calling pthread_yield all the time. Making ldap_pvt_thread_yield a no-op might help here... Thank you very much! I would also think that this might help. We have, however, fixed it by using FreeBSD until the problem is solved in Debian Sarge, too. For me there seem to be just two possibilities: - The use of the scheduler functions (or whatever leads to this) must be considered wrong and harmful in at least this case. Then a fix would be something like building the package with this function disabled, just as you have proposed. - It can not be strictly considered wrong. (After all, it apparently works perfectly with Debian Woody and FreeBSD.) Then one would have to find out where the thread handling within Debian Sarge breaks this correct use of functions, and fix the bug there. I would be very happy with either kind of solution. Since the package, in its current state, cannot be used by us and, as I presume, many other people, it would be a big improvement if the problem were solved before the release of Debian Sarge. I will try to continue to help with this. With kind regards Ulrich Hermisson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311491: slapd stops functioning almost completely if a CPU consuming process runs at the same time
On Wed, Jun 01, 2005 at 12:16:05PM +0200, Ulrich Hermisson wrote: > from www.openldap.org (compiled with "--enable-crypt"). Only when I > compile with the configure option "--with-threads=no", everything is > ok, but the slurpd needs threads. With threads, also the test 17 > performed by "make test" fails if a CPU consuming process is running > in parallel. I have reproduced the bug on the following > architectures/kernel versions (always with Debian Sarge): > Opteron/2.6.7, Opteron/2.6.11, Athlon/2.6.8, Pentium 4/2.6.8. With > Debian Woody on Pentium 4/2.6.7, everything works, also with FreeBSD. Known problem. I'd guess the reason is that OpenLDAP is calling pthread_yield all the time. Making ldap_pvt_thread_yield a no-op might help here... Greetings Torsten signature.asc Description: Digital signature
Bug#311491: slapd stops functioning almost completely if a CPU consuming process runs at the same time
Package: slapd Version: 2.2.23-5 Severity: important The slapd almost stops working while a CPU consuming process like the one started by echo 3^ | bc & is running on the same machine. That is: a query (e.g. querying a passwd database by pam_ldap) which is answered immediately (i.e. less than 1 second) if no such process is running in parallel can take more than half an hour. One can reduce it to a few minutes by increasing the priority of slapd to the maximum. If one kills the CPU consuming process, the query is answered immediately. The bug is completely reproducible, and I have also reproduced it with the newest version openldap-stable-20050429.tgz from www.openldap.org (compiled with "--enable-crypt"). Only when I compile with the configure option "--with-threads=no", everything is ok, but the slurpd needs threads. With threads, also the test 17 performed by "make test" fails if a CPU consuming process is running in parallel. I have reproduced the bug on the following architectures/kernel versions (always with Debian Sarge): Opteron/2.6.7, Opteron/2.6.11, Athlon/2.6.8, Pentium 4/2.6.8. With Debian Woody on Pentium 4/2.6.7, everything works, also with FreeBSD. With kind regards Ulrich Hermisson -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-386 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ISO-8859-1) (ignored: LC_ALL set to de_DE) Versions of packages slapd depends on: ii coreutils [fileutils] 5.2.1-2 The GNU core utilities ii debconf 1.4.30.13Debian configuration management sy ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libdb4.24.2.52-18Berkeley v4.2 Database Libraries [ ii libiodbc2 3.52.2-3 iODBC Driver Manager ii libldap-2.2-7 2.2.23-5 OpenLDAP libraries ii libltdl31.5.6-6 A system independent dlopen wrappe ii libperl5.8 5.8.4-8 Shared Perl library ii libsasl22.1.19-1.5 Authentication abstraction library ii libslp1 1.0.11a-2OpenSLP libraries ii libssl0.9.7 0.9.7e-3 SSL shared libraries ii libwrap07.6.dbs-8Wietse Venema's TCP wrappers libra ii perl [libmime-base64-perl] 5.8.4-8 Larry Wall's Practical Extraction ii psmisc 21.5-1 Utilities that use the proc filesy -- debconf information: slapd/fix_directory: true * shared/organization: math.uni-bielefeld.de slapd/upgrade_slapcat_failure: slapd/backend: BDB * slapd/allow_ldap_v2: true slapd/no_configuration: false slapd/move_old_database: true slapd/suffix_change: false slapd/slave_databases_require_updateref: slapd/dump_database_destdir: /var/backups/slapd-VERSION slapd/autoconf_modules: true * slapd/domain: math.uni-bielefeld.de slapd/password_mismatch: slapd/invalid_config: true slapd/upgrade_slapadd_failure: slapd/dump_database: when needed slapd/purge_database: false -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
