Quoting Quanah Gibson-Mount <[EMAIL PROTECTED]>: > --On Saturday, September 22, 2007 7:26 PM -0400 Jimi > <[EMAIL PROTECTED]> wrote: > >> Hi, >> >> We use Open Ldap with bdb, and after a import of about 15000 test users, >> searching for users doesn't seem possible anymore. About 2 hours ago I >> started a simple search for uid=a* (as a filter) that still hasn't >> finished. In slapd.conf I have loglevel 256 (and that is the default >> anyway, as I understand it). But it still logs tremendous amount of data, >> for this simple search. It writes about 40kb/s to the log file, and it is >> now about 250mb big (it started with an empty log file). If I 'tail' the >> file it doesn't give me any meaningful output. But maybe you guys can see >> something that I can't. > > How did you import the users? Did you create an index? What backend > are you using? etc.
The backend is bdb, if that is what you mean. The system is Red Hat Enterprise Linux ES release 4 (Nahant), and as far as I know both Openldap and BDB is whatever version that came with Redhat (installed last week). I wrote about the indexes before, they are: index objectClass,member eq,pres index ou,cn,sn,mail,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub The original import was made using the admin interface of our Content Managment System (an xml-file in the CMS system xml structure), and I have no idea how exactly the data was inserted into ldap. But it has worked fine before, with smaller data sets. > It certainly shouldn't take 2 hours. On a database with 400,000 > users using OpenLDAP 2.3 with back-hdb and BDB 4.2.52+ patches, it > takes: > > 13.82u 0.86s 0:25.69 57.1% > > 25.69 seconds Yes, I know that something must have been wrong. I finally stopped ldap and tomcat, and then started from scratch again. These were my steps now: 01. stop tomcat and ldap 02. rm -f /var/lib/ldap/data/* 03. rm -f /home/ldap/bdb_transaction_logs 04. run db_recover -c in /var/lib/ldap as user ldap 05. start ldap, verify status, check that files are created in /var/lib/ldap/data 06. stop ldap 07. add set_flags DB_TXN_NOSYNC in DB_CONFIG 08. run as user ldap: slapadd -l /var/lib/ldap/temp/testserver_dump_ldap_sep23.ldif 09. run db_recover -c in /var/lib/ldap as user ldap 10. /etc/init.d/ldap start 11. /etc/init.d/ldap status 12. /etc/init.d/tomcat start The ldif file was created using slapcat. I deliberately didn't comment out set_flags DB_TXN_NOSYNC in DB_CONFIG now, since I figure it should be set during the big import (same reason as think it should be set during slapadd). Is any of these steps bad? Am I doing something I shoudn't do? Or not doing something that I should? I am just now starting the import in the CMS. I will report how it goes. Regards /Jimi --- You are currently subscribed to [EMAIL PROTECTED] as: [EMAIL PROTECTED] To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the SUBJECT of the message.
