mariusp44(a)gmail.com wrote:
> I am running openldap 2.4.11
Note that this release is already a bit old. If you're testing it is
more helpful to use a recent release (like 2.4.15 at the moment).
Ciao, Michael.
Howard,
Thank you for your great knowledge in the OpenLDAP internals.
I will also give a try and check but looks like you could pinpoint the issue and solve it.
I would like to say this will greatly allow many users to control better memory usage and then have DBs bigger than available memory, what can be very common nowadays.
I normally will not have 2 process searching DB simultaneously, this was just a test. In this way performance, in average, will be reasonable.
Thanks a lot!
Rodrigo.
--- On Mon, 3/2/09, Howard Chu <hyc(a)symas.com> wrote:
> From: Howard Chu <hyc(a)symas.com>
> Subject: Re: (ITS#5860) slapd memeory leak under openldap 2.4
> To: rlvcosta(a)yahoo.com
> Cc: openldap-its(a)openldap.org
> Date: Monday, March 2, 2009, 4:36 AM
> Rodrigo Costa wrote:
> > Howard,
> >
> > One more comment. If you take a longer time between
> the ldapsearches the
> issue doesn't appear sometimes.
> >
> > So you need to start the first ldapsearh and like 15
> seconds later start
> > the
> second one. With this scenario the problem will for sure
> appear.
>
> I was finally able to reproduce this issue, by running two
> identical searches simultaneously on a server with more than
> 2 CPU cores. Given any delay between the two search
> invocation, the problem did not appear.
>
> This is now fixed in HEAD. Thanks for your help in
> providing data for reproducing the issue.
>
> > In this way we will see large chunks of memory being
> allocated and after
> > it
> stabilizes the query get stuck returning as the issue
> before 16 records per
> minute, or very slow and getting stuck all the time.
>
> I should point out - the memory use is stabilized now (as
> it should be) but the search performance of a configuration
> such as yours will be extremely poor due to the unavoidable
> thrashing that such a query pattern exerts on the cache.
> Setting a larger minfree can help reduce some of the
> contention but it will still be much slower than normal.
>
> > Regards,
> >
> > Rodrigo.
>
>
> -- -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP
> http://www.openldap.org/project/
Hello,
I am trying to change a password for ldap entry using ldappasswd -vx
-D "cn=root,dc=test,dc=com" -w foobarr
"uid=mariusp,ou=people,dc=test,dc=com" and reply I get is:
Result: Other (e.g., implementation specific) error (80)
Additional info: password hash failed
This error occurs if password-hash is set to SSHA, SMD5 and CRYPT. It
works fine if it is CLEARTEXT, SHA and MD5.
I am running openldap 2.4.11 on Solaris 10 latest on SPARC. It is in
testing meaning there is nothing special about its configuration all
defaults. Database has two entries just to play with.
Same error occurs if I use downloaded pre-compiled version from
sunfreeware.com or compile it myself using gcc.
Wondering if anyone experienced similar issue.
Regards,
/Marius
Rodrigo Costa wrote:
> Howard,
>
> One more comment. If you take a longer time between the ldapsearches the
issue doesn't appear sometimes.
>
> So you need to start the first ldapsearh and like 15 seconds later start
> the
second one. With this scenario the problem will for sure appear.
I was finally able to reproduce this issue, by running two identical searches
simultaneously on a server with more than 2 CPU cores. Given any delay between
the two search invocation, the problem did not appear.
This is now fixed in HEAD. Thanks for your help in providing data for
reproducing the issue.
> In this way we will see large chunks of memory being allocated and after
> it
stabilizes the query get stuck returning as the issue before 16 records per
minute, or very slow and getting stuck all the time.
I should point out - the memory use is stabilized now (as it should be) but
the search performance of a configuration such as yours will be extremely poor
due to the unavoidable thrashing that such a query pattern exerts on the
cache. Setting a larger minfree can help reduce some of the contention but it
will still be much slower than normal.
> Regards,
>
> Rodrigo.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Full_Name: Marius Paulauskas
Version: 2.4.11
OS: Solaris 10 (SPARC)
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (76.201.141.149)
I am trying to change a password for ldap entry using ldappasswd -vx
-D "cn=root,dc=test,dc=com" -w foobarr
"uid=mariusp,ou=people,dc=test,dc=com" and reply I get is:
Result: Other (e.g., implementation specific) error (80)
Additional info: password hash failed
This error occurs if password-hash is set to SSHA, SMD5 and CRYPT. It works fine
if it is CLEARTEXT, SHA and MD5.
I am running openldap 2.4.11 on Solaris 10 latest on SPARC. It is in testing
meaning there is nothing special about its configuration all defaults. Database
has two entries just to play with.
Same error occurs if I use downloaded pre-compiled version from sunfreeware.com
or compile it myself using gcc.
peter(a)adpm.de wrote:
> Full_Name: Peter Marschall
> Version: 2.4.15
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/Peter-Marschall-090301.patch
> Submission from: (NULL) (92.75.56.86)
>
>
> Hi,
>
> when OpenLDAP 2.4.15 is compiled with GnuTLS, then setting
> TLSVerifyClient Try
> in slapd.conf makes TLS connections without certificates impossible.
>
> This is caused by incomplete decoding in tls_g.c
>
> The patch in ftp://ftp.openldap.org/incoming/Peter-Marschall-090301.patch
> fixes this issue together with a few other little cleanups:
> - remove unused variables (less compiler warnings)
> - use correct types (less compiler warnings)
> - detect failed calls for activation/exiration functions to
> avoid giving wrong information
>
> Please consider adding this patch to OpenLDAP
Thanks for the patch, committed to HEAD.
>
> Regards
> Peter
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Full_Name: Peter Marschall
Version: 2.4.15
OS: Linux
URL: ftp://ftp.openldap.org/incoming/Peter-Marschall-090301.patch
Submission from: (NULL) (92.75.56.86)
Hi,
when OpenLDAP 2.4.15 is compiled with GnuTLS, then setting
TLSVerifyClient Try
in slapd.conf makes TLS connections without certificates impossible.
This is caused by incomplete decoding in tls_g.c
The patch in ftp://ftp.openldap.org/incoming/Peter-Marschall-090301.patch
fixes this issue together with a few other little cleanups:
- remove unused variables (less compiler warnings)
- use correct types (less compiler warnings)
- detect failed calls for activation/exiration functions to
avoid giving wrong information
Please consider adding this patch to OpenLDAP
Regards
Peter