[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: adding entry, indexing takes too long (ITS#3081)
As this problem appears to be either the result of improper configuration
of Berkeley DB or a bug in Berkeley DB (I note that Sleepycat does offer
updated versions/patches which might have an impact here), I intended
to close this report unless someone can demonstrate a bug in OpenLDAP
Software itself.
Kurt
At 04:07 PM 4/13/2004, jmcclure@lucent.com wrote:
>Full_Name: James McClure
>Version: 2.1.28
>OS: Solaris 9
>URL: ftp://ftp.openldap.org/incoming/
>Submission from: (NULL) (65.247.141.10)
>
>
>Hi,
>
>I am running into intermittant ADD issues where the 2.1.28 server is busy trying
>to do the indexing portion of an ADD operation and not returning a response to
>the client in a timely manner (see below). My client has a client-side timeout
>of 15 seconds, at which time the operation is abandoned and retries the
>operation again. The client-side timeout has been increased and does not
>resolve the issue. Cannot find specific reference to any outstanding issues
>that remotely resembles this symptom. Any help/direction appreciated. Thanks.
>
>James McClure
>
>
>...initial ADD operation snip...
>oc_check_allowed type "creatorsName"
>oc_check_allowed type "createTimestamp"
>oc_check_allowed type "entryCSN"
>oc_check_allowed type "modifiersName"
>oc_check_allowed type "modifyTimestamp"
>bdb_dn2entry_rw("ou=mears,ou=ecm,o=company,c=ca")
>=> bdb_dn2id_matched( "ou=mears,ou=ecm,o=company,c=ca" )
>====> bdb_cache_find_entry_dn2id("ou=mears,ou=ecm,o=company,c=ca"): 1 (1 trie
>s)
>====> bdb_cache_find_entry_id( 1 ) "ou=mears,ou=ecm,o=company,c=ca" (found) (
>1 tries)
>=> access_allowed: write access to "ou=mears,ou=ecm,o=company,c=ca" "children
>" requested
><= root access granted
>====> bdb_unlocked_cache_return_entry_r( 1 ): returned (0)
>=> access_allowed: write access to
>"msgSequenceNumber=4480821,ou=mears,ou=ecm,o=
>company,c=ca" "entry" requested
><= root access granted
>=> bdb_dn2id_add( "msgSequenceNumber=4480821,ou=mears,ou=ecm,o=company,c=ca",
> 0x003a0505 )
>bdb_idl_insert_key: 3a0505 %ou=mears,ou=ecm,o=company,c=ca
><= bdb_dn2id_add: 0
>=> entry_encode(0x003a0505):
>msgSequenceNumber=4480821,ou=mears,ou=ecm,o=company
>,c=ca
>=> index_entry_add( 3802373,
>"msgSequenceNumber=4480821,ou=mears,ou=ecm,o=company
>,c=ca" )
>
>*******hung up here********
>
>...second retry snip...
>ber_dump: buf=0x01c32fc8 ptr=0x01c332ac end=0x01c332c3 len=23
> 0000: 30 15 04 0e 6d 73 67 76 6f 69 63 65 6c 65 6e 67 0...msgvoiceleng
> 0010: 74 68 31 03 04 01 30 th1...0
>ber_scanf fmt (}) ber:
>ber_dump: buf=0x01c32fc8 ptr=0x01c332c3 end=0x01c332c3 len=0
>
>conn=1 op=3 ADD dn="msgSequenceNumber=4480821,ou=mears,ou=ecm,o=company,c=ca"
>bdb_dn2entry_rw("msgSequenceNumber=4480821,ou=mears,ou=ecm,o=company,c=ca")
>=> bdb_dn2id_matched( "msgSequenceNumber=4480821,ou=mears,ou=ecm,o=company,c=
>ca" )
>=> key_change(ADD,3a0505)
>bdb_idl_insert_key: 3a0505 [00000001]
><= key_change 0
>=> key_change(ADD,3a0505)
>bdb_idl_insert_key: 3a0505 [0096defd]
><= key_change 0
>=> key_change(ADD,3a0505)
>bdb_idl_insert_key: 3a0505 [b2dd19a6]
><= key_change 0
>=> key_change(ADD,3a0505)
>bdb_idl_insert_key: 3a0505 [97e2e6d7]
><= key_change 0
>
>*******hung up here********
>
>...third attempt snip...
>ber_dump: buf=0x0df0b3a8 ptr=0x0df0b68c end=0x0df0b6a3 len=23
> 0000: 30 15 04 0e 6d 73 67 76 6f 69 63 65 6c 65 6e 67 0...msgvoiceleng
> 0010: 74 68 31 03 04 01 30 th1...0
>ber_scanf fmt (}) ber:
>ber_dump: buf=0x0df0b3a8 ptr=0x0df0b6a3 end=0x0df0b6a3 len=0
>
>conn=1 op=5 ADD dn="msgSequenceNumber=4480821,ou=mears,ou=ecm,o=company,c=ca"
>bdb_dn2entry_rw("msgSequenceNumber=4480821,ou=mears,ou=ecm,o=company,c=ca")
>=> bdb_dn2id_matched( "msgSequenceNumber=4480821,ou=mears,ou=ecm,o=company,c=
>ca" )
>=> key_change(ADD,3a0505)
>bdb_idl_insert_key: 3a0505 [a26dbf5c]
><= key_change 0
>
>*******hung up here********
>
>
>Environment is OpenLDAP 2.1.28 w/BDB 4.1.25 on Solaris 9.
>
>slapd.conf Configuration:
>
>database bdb
>suffix "ou=mears,ou=ecm,o=company,c=ca"
>index msgStatusCode eq
>index msgEventDescriptor eq
>index msgMessageUID eq
>index msgVMUID eq
>subordinate
>directory /export/home/billing/ecm/mears
>cachesize 100000
>checkpoint 0 30
>rootdn cn=admin,ou=users,o=company,c=ca
>index objectClass pres,eq
>index msgEventTimestamp pres,eq
>index msgSenderAddress eq
>index msgRecipientAddress eq
>sizelimit unlimited
>timelimit unlimited
>
>DB directory content:
>
>drwxrwx--- 2 root mlall 25600 Apr 13 19:02 .
>drwxrwx--- 8 root mlall 512 Apr 1 14:27 ..
>-rw-rw-r-- 1 root other 105 Apr 6 15:58 DB_CONFIG
>-rw-r----- 1 root other 8192 Apr 13 19:00 __db.001
>-rw-r----- 1 root other 131080192 Apr 13 18:36 __db.002
>-rw-r----- 1 root other 98304 Apr 13 17:42 __db.003
>-rw-r----- 1 root other 42123264 Apr 13 17:41 __db.004
>-rw-r----- 1 root other 16384 Apr 13 18:36 __db.005
>-rw------- 1 root other 1164840960 Apr 13 18:11 dn2id.bdb
>-rw------- 1 root other 4457201664 Apr 13 18:11 id2entry.bdb
>-rw------- 1 root root 10485736 Apr 13 18:33 log.0000001970
>-rw------- 1 root root 5674729 Apr 13 18:36 log.0000001971
>-rw------- 1 root other 2236416 Apr 13 18:11 msgEventDescriptor.bdb
>-rw------- 1 root other 158085120 Apr 13 18:11 msgEventTimestamp.bdb
>-rw------- 1 root other 79237120 Apr 13 18:11 msgMessageUID.bdb
>-rw------- 1 root other 81137664 Apr 13 18:11 msgRecipientAddress.bdb
>-rw------- 1 root other 92348416 Apr 13 18:11 msgSenderAddress.bdb
>-rw------- 1 root other 3338240 Apr 13 18:11 msgStatusCode.bdb
>-rw------- 1 root other 29843456 Apr 13 18:11 msgVMUID.bdb
>-rw------- 1 root other 2023424 Apr 13 18:11 objectClass.bdb