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

Re: Very slow ldapserach



--On Wednesday, April 08, 2015 11:58 AM +0200 Saša-Stjepan Bakša <ssbaksa@gmail.com> wrote:






On 7 April 2015 at 21:14, Quanah Gibson-Mount <quanah@zimbra.com> wrote:

--On Tuesday, April 07, 2015 1:10 PM -0700 Quanah Gibson-Mount
<quanah@zimbra.com> wrote:



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


Sounds like there's something wrong with your openldap build or server.
Zimbra has clients with DBs of various sizes and entry counts, often in
the multi-GBs, and we're not seeing any such issues.


Actually, you are doing alias deref.  I believe there's a known issue
with back-mdb and alias deref.  Do you see the same behavior if you
select -a never instead?



--Quanah




Yes, we are depending on aliases. Without them we will need at least 2
searches to get data we need. In new version even more because we have
data which is similar to many users and we use another aliases inside
each user to fetch that data for particular user. Let we say that each
user have 3 aliases to 3 groups of data which can have at leas 30
different possibilities for each user. Without aliases data size for each
user will be to big and in summary database will be huge.


I have tested search with your suggestion. No crash - slapd crashes only
when deref is on or in best case it is slow (10 to 20 seconds for
answer). As I have said, when database is small (relative size) it is
quick as we expected.


So, which alternatives do I have? Back to hdb? Uh, I don't like it to
much.

Is this long standing issue a big problem to solve? I am not developer so
maybe this was a rude question (sorry!).

Please keep replies on the list if you want help.

My guess is this is ITS#7657.

--Quanah


--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration