RE: (ITS#5026) LDAP Search very slow > 2mins
by andy.yip＠newworldtel.com
Dear sir,
We found the ldap search is slow running. Please advise how to fine tune
the database. I am not sure adding cache size or perform db_recover will
solve the problem
Regards,
Andy
-----Original Message-----
From: Hallvard Breien Furuseth [mailto:h.b.furuseth@usit.uio.no]
Sent: Wednesday, June 20, 2007 10:39 PM
To: Yip S C, Andy (NS NWT)
Cc: openldap-its(a)openldap.org
Subject: Re: (ITS#5026) LDAP Search very slow > 2mins
Please take this to the mailinglist openldap-software(a)openldap.org. The
ITS system is for bug reports, feature requests etc. This ITS will be
closed.
Note however that there never was an OpenLDAP version 1.8.8.7. So I
wonder if your trouble is with a Sun LDAP server instead.
--
Regards,
Hallvard
15 years, 11 months
Re: (ITS#4959) replica seg faults if syncrepl searchbase =""
by ali.pouya＠free.fr
h.b.furuseth(a)usit.uio.no wrote :
>That's from ITS#4975: The code was broken for builds without TLS.
>It's been fixed in HEAD. Does it work now?
Hi Hallvard,
Yes I confirm that the problem with TLS compilation is fixed now.
But the main problem of this ITS still remains (replica seg faults if syncrepl
searchbase ="").
Sorry for this late answer.
Best regards
Ali
15 years, 11 months
Re: (ITS#5022) ldappasswd crash consumer slapd with some loglevels
by gao＠schrodinger.com
Pierangelo Masarati wrote:
> Simon Gao wrote:
>
>
>> OpenLDAP-2.3.36 fixed the problem. Now at loglevel 0, 512, 256, slapd no
>> longer crashes. You can go ahead close 5022 and 5023.
>>
>
> OK. Then I think the different behavior at different loglevel was
> actually a side effect of something related to ITS#4964.
>
>
>> Should I also update provider to 2.3.36?
>>
>
> AFAIK, no. Please make sure that the password change, besides
> succeeding, is correctly replicated. While fixing ITS#4964, a companion
> bug in the provider was discovered, but it appeared to be related to
> code development that's not in the 2.3 release (ITS#4973).
>
>
Replications works fine. I tries changing password 5 or 6 times,
replication worked each time. I will hold on upgrading provider for now.
Thanks again.
Simon
15 years, 11 months
Re: (ITS#5022) ldappasswd crash consumer slapd with some loglevels
by ando＠sys-net.it
Simon Gao wrote:
> OpenLDAP-2.3.36 fixed the problem. Now at loglevel 0, 512, 256, slapd no
> longer crashes. You can go ahead close 5022 and 5023.
OK. Then I think the different behavior at different loglevel was
actually a side effect of something related to ITS#4964.
> Should I also update provider to 2.3.36?
AFAIK, no. Please make sure that the password change, besides
succeeding, is correctly replicated. While fixing ITS#4964, a companion
bug in the provider was discovered, but it appeared to be related to
code development that's not in the 2.3 release (ITS#4973).
Cheers, p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 11 months
Re: (ITS#5022) ldappasswd crash consumer slapd with some loglevels
by gao＠schrodinger.com
Pierangelo Masarati wrote:
> gao(a)schrodinger.com wrote:
>
>
>> slapd: result.c:364: send_ldap_response: Assertion `rs->sr_err != 0x0a'
>> failed.
>>
>
> __Could__ be the same as ITS#4964, which was fixed in OpenLDAP 2.3.36
> just released, apart from depending on the log level, which I definitely
> consider odd.
>
> Can you check if the problem persists with the latest release?
>
>
OpenLDAP-2.3.36 fixed the problem. Now at loglevel 0, 512, 256, slapd no
longer crashes. You can go ahead close 5022 and 5023.
Should I also update provider to 2.3.36?
Thanks,
Simon
15 years, 11 months
RE: slapd+pcache keeps crashing on FreeBSD 6.2 (ITS#4841)
by imriz＠co.zahav.net.il
Hi Howard,
I've reduced the threads to 4 (number of cpus), and I still get frequent
coredumps:
#0 0xa83ba58a in strcasecmp () from /lib/libc.so.6
[New Thread 0x9e31800 (LWP 100335)]
[New Thread 0x81eb500 (LWP 100316)]
[New Thread 0x8188a00 (LWP 100185)]
[New Thread 0x81cff00 (LWP 100146)]
[New Thread 0x81c9800 (LWP 100069)]
[New Thread 0x813a000 (LWP 100626)]
(gdb) bt
#0 0xa83ba58a in strcasecmp () from /lib/libc.so.6
#1 0x080a93d0 in an_find (a=0xa81b6f0, s=0x830b2a4) at ad.c:842
#2 0x080d5a41 in add_filter_attrs (op=0xa78a800, new_attrs=0xbf1fc8c4,
attrs=0x81863e0, filter_attrs=0x830b27c, fattr_cnt=3,
fattr_got_oc=0) at pcache.c:1140
#3 0x080d6260 in pcache_op_search (op=0xa78a800, rs=0xbf1fcd70) at
pcache.c:1313
#4 0x080c8401 in overlay_op_walk (op=0xa78a800, rs=0xbf1fcd70,
which=op_search, oi=0x813ae00, on=0x813af00) at backover.c:498
#5 0x080c861d in over_op_func (op=0xa78a800, rs=0xbf1fcd70,
which=op_search) at backover.c:560
#6 0x080c869a in over_op_search (op=0xa78a800, rs=0xbf1fcd70) at
backover.c:582
#7 0x0806ec33 in fe_op_search (op=0xa78a800, rs=0xbf1fcd70) at
search.c:355
#8 0x0806e752 in do_search (op=0xa78a800, rs=0xbf1fcd70) at
search.c:217
#9 0x0806c1b7 in connection_operation (ctx=0xbf1fce00, arg_v=0xa78a800)
at connection.c:1133
#10 0xa816be00 in ldap_int_thread_pool_wrapper (xpool=0x8148340) at
tpool.c:478
#11 0xa830e5cf in pthread_create () from /usr/lib/libthr.so.2
#12 0x00000000 in ?? ()
> -----Original Message-----
> From: Howard Chu [mailto:hyc@symas.com]
> Sent: Wednesday, June 20, 2007 10:02 AM
> To: Imri Zvik
> Cc: openldap-its(a)openldap.org
> Subject: Re: slapd+pcache keeps crashing on FreeBSD 6.2 (ITS#4841)
>
> It appears that your system has simply run out of memory, most likely
> because
> you have 34 active threads in the process. That's far too many threads
> for a
> typical 32 bit machine.
>
> Imri Zvik ( Smile ) wrote:
> > I have new tar.gz file ready, this time with unstripped binaries:
> > http://mariska.inter.net.il/~imriz/slapd-crash-10042007.tar.gz
> >
> > root@cemetery:~$ ldd /usr/local/libexec/slapd
> > /usr/local/libexec/slapd:
> > libldap_r-2.3-releng.so.2 =>
> > /usr/local/lib/libldap_r-2.3-releng.so.2 (0xa8161000)
> > liblber-2.3-releng.so.2 =>
> > /usr/local/lib/liblber-2.3-releng.so.2 (0xa81a1000)
> > libssl.so.4 => /usr/lib/libssl.so.4 (0xa81b7000)
> > libcrypto.so.4 => /lib/libcrypto.so.4 (0xa81e5000)
> > libfetch.so.4 => /usr/lib/libfetch.so.4 (0xa82d8000)
> > libcom_err.so.3 => /usr/lib/libcom_err.so.3 (0xa82e5000)
> > libcrypt.so.3 => /lib/libcrypt.so.3 (0xa82e7000)
> > libltdl.so.4 => /usr/local/lib/libltdl.so.4 (0xa82ff000)
> > libpthread.so.2 => /usr/lib/libthr.so.2 (0xa8307000)
> > libc.so.6 => /lib/libc.so.6 (0xa8319000)
> > root@cemetery:~$ file /usr/local/libexec/slapd
> > /usr/local/libexec/slapd: ELF 32-bit LSB executable, Intel 80386,
> > version 1 (FreeBSD), dynamically linked (uses shared libs), not
> stripped
> >
> > Please let me know if there is anything else you need,
> >
> > --imriz
> >
> >
> >> -----Original Message-----
> >> From: Howard Chu [mailto:hyc@symas.com]
> >> Sent: Tuesday, April 03, 2007 12:42 AM
> >> To: Imri Zvik ( Smile )
> >> Cc: openldap-its(a)openldap.org
> >> Subject: Re: slapd+pcache keeps crashing on FreeBSD 6.2 (ITS#4841)
> >>
> >> imriz(a)co.zahav.net.il wrote:
> >>> Sure. New core dumps and binary file is at
> >>> http://mariska.inter.net.il/~imriz/slapd-core.tar.gz
> >> The slapd in this snapshot was stripped so no debug symbols are
> >> present.
> >> Please be sure to use an unstripped binary.
> >>
> >> Also, since you're also loading libldap_r, liblber, back-ldap,
back-
> >> bdb,
> >> back-meta, and back-ldbm dynamically, you'll need to include those
> >> modules in the tarball. (Also with debug and unstripped.)
> >>
> >> Although at this point I'm wondering why you're using back-ldbm,
> which
> >> has been deprecated for quite a long time.
> >>
> >>> Please notice that the previous dump was from FreeBSD ports
> > (OpenLDAP
> >>> version 2.3.33).
> >>>
> >>> This one was fetched from the CVS (OPENLDAP_REL_ENG_2_3), with the
> >>> following configure options:
> >>>
> >>> ./configure --with-threads=posix --with-tls=openssl --enable-
> dynamic
> >>> --without-cyrus-sasl --enable-modules --localstatedir=/var/
> >>> db --enable-ldbm=mod --enable-crypt --enable-lmpasswd --enable-
> >> ldap=mod
> >>> --enable-meta=mod --enable-rewrite --enable-null=mod --enabl
> >>> e-monitor=mod --enable-proxycache --disable-syncprov
> > --enable-bdb=mod
> >>> --enable-hdb=mod --enable-dbm-api=berkeley --disable-slurpd --
> >>> prefix=/usr/local --enable-debug
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: Howard Chu [mailto:openldap-its@OpenLDAP.org]
> >>> Sent: Tuesday, February 13, 2007 1:14 AM
> >>> To: Imri Zvik
> >>> Subject: Re: slapd+pcache keeps crashing on FreeBSD 6.2 (ITS#4841)
> >>>
> >>> It looks like this core is from a binary without debug symbols
> >> present,
> >>> can you
> >>> recompile with debugging enabled and get a new stack trace and
core
> >>> file?
>
> --
> -- Howard Chu
> Chief Architect, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
15 years, 11 months
Re: (ITS#5026) LDAP Search very slow > 2mins
by h.b.furuseth＠usit.uio.no
Please take this to the mailinglist openldap-software(a)openldap.org. The
ITS system is for bug reports, feature requests etc. This ITS will be
closed.
Note however that there never was an OpenLDAP version 1.8.8.7. So I
wonder if your trouble is with a Sun LDAP server instead.
--
Regards,
Hallvard
15 years, 11 months
Re: (ITS#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no
About context_reset() in pool_wrapper(): Yes, it works out. Anyway I
completely lost that kfree functions may not lock ltp_mutex since it's
already locked (again unless they go active). Will just document that
they may not call functions which take a pool argument anyway - they can
only use the context. Will also insert various asserts about how
the pool should be used (pause/pause etc.)
Another detail:
tpool.c tracks task counts as 'long's, but pool_query() and
pool_backload() return them in 'int's. Can use int counts
instead and set a max pending limit of INT_MAX - LDAP_MAXTHR.
--
Regards,
Hallvard
15 years, 11 months
