[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Very slow ldapserach





On 9 April 2015 at 02:37, Quanah Gibson-Mount <quanah@zimbra.com> wrote:
--On Wednesday, April 08, 2015 8:51 PM +0200 Saša-Stjepan Bakša <ssbaksa@gmail.com> wrote:

I am sorry for this mistake with answering to you and not to the group.
It was unintentional mistake. 


Ok, I will check ITS#7657.

Please try current RE24 code.  It is believed the fixes for ITS#8011 which are scheduled to be part of the 2.4.41 relase should resolve the issue.

Thanks,

Quanah


At 8:00 local time:
git checkout OPENLDAP_REL_ENG_2_4
git pull

Build + test

root@test:~# date; ldapsearch -h 10.14.252.103 -p 389 -D cn=admin,dc=spr -w siemens -s sub -a always -b msisdn=385212000009,dc=MSISDN,dc=SPR objectClass=*; date
Thu Apr  9 08:22:46 CEST 2015
# extended LDIF
#
# LDAPv3
# base <msisdn=385212000009,dc=MSISDN,dc=SPR> with scope subtree
# filter: objectClass=*
# requesting: ALL
#
 ----- cut------
# search result
search: 2
result: 0 Success

# numResponses: 9
# numEntries: 8
Thu Apr  9 08:23:38 CEST 2015

Nothing changed yet - 52 seconds

And search for all still crashes openldap server

ldapsearch -h 10.14.252.103 -p 389 -D cn=admin,dc=spr -w siemens -s sub -a always -b dc=SPR objectClass=*

552641e7 >>> dnPrettyNormal: <dc=SPR>
552641e7 <<< dnPrettyNormal: <dc=SPR>, <dc=spr>
ber_scanf fmt (m) ber:
ber_scanf fmt ({M}}) ber:
552641e7 => mdb_search
552641e7 mdb_dn2entry("dc=spr")
552641e7 => mdb_dn2id("dc=spr")
552641e7 <= mdb_dn2id: got id=0x1
552641e7 => mdb_entry_decode:
552641e7 <= mdb_entry_decode
552641e7 search_candidates: base="dc=spr" (0x00000001) scope=2
552641e7 => mdb_equality_candidates (objectClass)
552641e7 => key_read
552641e7 <= mdb_index_read 10000000 candidates
552641e7 <= mdb_equality_candidates: id=-1, first=16, last=10000015
Segmentation fault

I must wait for 2.4.41 release then. In the mean time I will use LTB project build with HDB to see can I have that version in working state for my colleagues test suite.

Br

Sasa