Re: subject=(ITS#2610)

[edg72@home.nl]

Kurt,

I already did apply that patch, I should have mentioned that in my previous 
mails. The good news is that 2603 may be solved, at least on Linux because by 
applying the patch the loads of "select timeout - yielding" log statements 
are gone. I can do some further testing on Solaris and Tru64 just to be sure. 
The bad news is that with that patch, I still see the behaviour as described  
in ITS2610, so unfortunately it isn't a solution for that.

Regards,

Erik

On Thursday 26 June 2003 22:56, Kurt@OpenLDAP.org wrote:
> 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