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

Re: subject=(ITS#2610)



This sounds like the same as ITS#2603.  You might try the
suggested fix or OPENLDAP_REL_ENG_2_1.

BTW, some ITS reports require human intervention (by me) in forwarding to
the -bugs list.  I just haven't gotten to the report yet.  But now that
you forwarded the issue yourself, I won't bother to forward the copies in
my review queue.  But I will now close ITS#2611 as a duplicate of ITS#2610.

Kurt

At 12:38 PM 6/26/2003, edg72@home.nl wrote:
>Hi,
>
>I already posted this issue via the ITS webinterface, but I had some problems 
>with my browser. Although the issue seems to be stored (actually twice, 
>sorry), I did not see it on the ITS maillinglist.
>
>I am currently investigating this issue further and I hope to get back to you 
>soon with more details.
>
>Here it is:
>
>*********************
>I did some modify and add benchmark testing (see below for testenvironment
>details) with OpenLDAP 2.1.21 on Linux with the bdb backend. When using 1 or 2
>client connections I achieve reasonable modify speed, given my 
>testenvironment, on an indexed attribute (about 45 modify/sec). When I use 3 
>or more client connections, the modify speed drops dramatically to about 1 
>modify/sec or even lower and I see that the slapd takes about 100% CPU time. 
>The same behaviour is seen when doing adds with multiple client connections. 
>When using strace on Linux I can see that loads of sched_yield() systemcalls 
>are being done. The sched_yield() systemcall asks the scheduler to schedule 
>another process/thread.
>Within OpenLDAP this system call is done from ldap_pvt_thread_yield() in
>libraries/libldap_r/thr_posix.c. When I change this function such that it does 
>a usleep for 100 usec and then returns, OpenLDAP does not show the behaviour 
>as described above and achieves good modify performance with up to 20 clients 
>using considerably less CPU time. I am certainly not saying that the change I 
>made is a suitable solution, but at least it shows that the problem is 
>somehow related to ldap_pvt_thread_yield()
>I've tested the original OpenLDAP 2.1.21 on HP Tru64 4.0F and SUN Solaris 2.8 
>as well, and the modify/add performance problem dit not show up on those OSes
>allthough the slapd uses about 100% CPU time just as under Linux.
>
>Below some details of my testenvironment:
>
>Compaq Evo P4@1.7GHz, 256 MB Ram, IDE harddisk, RedHat Linux 7.3
>(hardly a suitable LDAP server, I know :-)
>Compaq DS10 Alpha@466MHz, 512MB Ram, SCSI harddisk, Tru64 4.0F
>SUN Netra X1 SparcII@400MHz, 256MB Ram, IDE harddisk, Solaris 2.8
>
>bdb part slapd.conf:
>database        bdb
>suffix          ""
>rootdn          "cn=Directory Manager"
># rootdn password (cleartext!)
>rootpw          (************)
>directory       /usr/ldap/var/openldap-data
>index           objectclass,uid,url,tag,aliasname,tetraipaddr,cdpdipaddr
>pres,eq
>checkpoint      5120 5
>cachesize       100
>
>DB_CONFIG
>set_cachesize 0 5242880 1
>set_lg_dir /usr/ldap/var/openldap-data
>#Just use this setting when doing slapadd...
>#set_flags DB_TXN_NOSYNC
>
>I've also tested with cachesize 0 and 100MB, but is does not have any effect 
>on the problem described above.
>*****************************
>
>Best Regards,
>
>Erik de Groot