[Date Prev][Date Next]
> Pierangelo Masarati wrote:
>> Also, note that if you submit a large number of simultaneous
>> those that exceed the number of available threads are queued and remain
>> pending. I guess the sigsegv is a bug, and it would be nice to be able
>> to track it down. I haven't been able to generate it on my system, so
>> might be something related to your setupo, or at least something that
>> depends on the rest of the environmet. However, in your case, if you
>> think your production system may be undergoing a high load, you might
>> to increase the number of available threads.
> OK. I recompiled with "--enable-threads=no" and still get crashes.
> Should that eliminate threads as a problem?
There's no --enable-threads switch in OpenLDAP's configure. There's a
In any case, I think back-ldap definitely needs threads and, provided the
system threads are not buggy, their use with slapd should be relatively
safe and beneficial in all cases. I think you just need to boost the
number of simultaneous threads your slapd can handle. The default is 16,
and if you want to deal with 512 simultaneous connections you could try
"threads 64" or "threads 128" (if your hardware can stand it, i.e. you are
using a 2/4 CPU system with a lot of ram and overall good performance,
including network bandwidth). Otherwise, you cannot simply accept so many
simultaneous connections with your hardware, sigsegv or not.
> If I do the "--num-forks=512" test with the two machines hitting the
> *BDB* backend, there is no crash. The entire test case completes fine.
> It seems that only the *LDAP* backend is causing a crash. (This could
> be due to something else, though, like a linear vs. exponential demand
> on resources.)
Are the back-ldap and back-bdb in the same slapd? If not, are they
on the same machine? On my laptop (a much older RH 7.1) when I try
such an intensive test, the system runs out of file descriptors way
before 128 simultaneous processes are started, and slapd hangs after
a while. However, when I kill the requests and the machine load
decreases a bit, the slapd goes (slowly) back to service. I used
your config file, and I hit a test database containing a few tenths
of entries, but this should not be an issue.
> What's weird to me is that "libpthread" is still linked in even when
> # ldd `which slapd`
> libdb-4.2.so => /usr/lib/libdb-4.2.so (0xb7500000)
> libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0xb74ea000)
> libssl.so.4 => /lib/libssl.so.4 (0xb74b5000)
> libcrypto.so.4 => /lib/libcrypto.so.4 (0xb73c3000)
> libcrypt.so.1 => /lib/libcrypt.so.1 (0xb7396000)
> libresolv.so.2 => /lib/libresolv.so.2 (0xb7384000)
> libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb7373000)
> libc.so.6 => /lib/tls/libc.so.6 (0xb723b000)
> libdl.so.2 => /lib/libdl.so.2 (0xb7238000)
> libgssapi_krb5.so.2 => /usr/kerberos/lib/libgssapi_krb5.so.2
> libkrb5.so.3 => /usr/kerberos/lib/libkrb5.so.3 (0xb71c7000)
> libcom_err.so.3 => /usr/kerberos/lib/libcom_err.so.3 (0xb71c5000)
> libk5crypto.so.3 => /usr/kerberos/lib/libk5crypto.so.3
> libz.so.1 => /usr/lib/libz.so.1 (0xb71a6000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb75eb000)
> Are there any potential incompatibilities with threading between
> OpenLDAP and these libraries? Are there other libraries I should
> recompile/upgrade/remove to do further testing?
> Thank you very very much,
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497