[Date Prev][Date Next]
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.
At 12:38 PM 6/26/2003, firstname.lastname@example.org wrote:
>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
>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:
>rootdn "cn=Directory Manager"
># rootdn password (cleartext!)
>checkpoint 5120 5
>set_cachesize 0 5242880 1
>#Just use this setting when doing slapadd...
>I've also tested with cachesize 0 and 100MB, but is does not have any effect
>on the problem described above.
>Erik de Groot