Yes I did and I increased the number 1234567 -> 5000000 , but still same
problem happening.
Thanks !
-aleks
-----Original Message-----
From: Jan-Michael Ong [mailto:jmong@adobe.com]
Sent: Monday, November 05, 2001 10:52 AM
To: Aleks Sheynkman
Subject: RE: performance problem with sldap
but did you add the sockbuf_max stuff in too in your slapd.conf??
jm
At 10:43 AM 11/5/2001 -0800, you wrote:
>OK, Upgrading to 2.0.18 did not help still the same problem occurs.
>
>-Aleks
>
>-----Original Message-----
>From: Jan-Michael Ong [mailto:jmong@adobe.com]
>Sent: Monday, November 05, 2001 10:44 AM
>To: Aleks Sheynkman
>Cc: openldap-software@OpenLDAP.org
>Subject: RE: performance problem with sldap
>
>
>I don't think so... The only way I can think off is that you do a dump of
>your database as an LDIF (using slapcat) and importing back the LDIF into
>the LDAP (using slapadd)
>
>good luck
>
>jm
>
>At 10:11 AM 11/5/2001 -0800, you wrote:
> >Is there are way to migrate database from version to version?
> >
> >Thanks !
> >-Aleks
> >
> >-----Original Message-----
> >From: Jan-Michael Ong [mailto:jmong@adobe.com]
> >Sent: Monday, November 05, 2001 10:08 AM
> >To: Aleks Sheynkman
> >Cc: openldap-software@OpenLDAP.org
> >Subject: RE: performance problem with sldap
> >
> >
> >You may be running into the sockbuf_max_incoming limit, adjust this in
> >your slapd.conf. (thanks Kurt Zeilenga)
> >
> >here's a sample
> >
> > Define global ACLs to disable default read access.
> >
> ># Do not enable referrals until AFTER you have a working directory
> ># service AND an understanding of referrals.
> >#referral ldap://root.openldap.org
> >
> >pidfile /usr/local/var/slapd.pid
> >argsfile /usr/local/var/slapd.args
> >loglevel 256
> >sizelimit 5
> >timelimit 3600
> >schemacheck on
> >sockbuf_max_incoming 1234567 <--- adjust this to a higher number or
> >define it if you do not have it defined.
> >
> >I don't know what causes it though. Also I upgraded from Openldap-2.0.11
to
> >Openldap-2.0.18 and db-3.2.9 to db 3-3.11 that seemed to solve other
> >problems
> >
> >good luck
> >
> >jm
> >
> >
> >
> >At 09:40 AM 11/5/2001 -0800, you wrote:
> > >Does anyone have any ideas what might cause this problem? Please
help..!!
> > >
> > >
> > >Thanks a lot in advance !
> > >
> > >-Aleks
> > >
> > >-----Original Message-----
> > >From: Aleks Sheynkman
> > >Sent: Monday, November 05, 2001 8:53 AM
> > >To: Aleks Sheynkman; 'Jonghyuk Choi'; 'res0k3ja@verizon.net'
> > >Cc: 'openldap-software@OpenLDAP.org'
> > >Subject: RE: performance problem with sldap
> > >
> > >
> > >I ran the same test on another server which has only 200 entries.
>Basically
> > >same behavior is happening after 3,000 continues searches ldapsearch
stat
> > >throwing "Can't contact LDAP server" errors.
> > >
> > >Thanks !
> > >
> > >-Aleks
> > >
> > >-----Original Message-----
> > >From: Aleks Sheynkman
> > >Sent: Monday, November 05, 2001 7:45 AM
> > >To: 'Jonghyuk Choi'; 'res0k3ja@verizon.net'
> > >Cc: openldap-software@OpenLDAP.org
> > >Subject: RE: performance problem with sldap
> > >
> > >
> > >I increased
> > >from :
> > >cachesize 100000000
> > >dbcachesize 320000000
> > >
> > >to
> > >cachesize 1000000000
> > >dbcachesize 1000000000
> > >sizelimit 5000000
> > >
> > >Also I added cachesize. Server seems to be up and running all the time.
> >When
> > >I do 5,000 searches , first 3,000 goes very fast and then it starts
> >printing
> > >error messages "ldap_bind: Can't contact LDAP server".
> > >
> > >I running server following platform:
> > > Linux 6.2.
> > > 2x750 MHz
> > > 2GB RAM
> > >
> > >Thanks !
> > >
> > >-Aleks
> > >-----Original Message-----
> > >From: Jonghyuk Choi [mailto:jongchoi@us.ibm.com]
> > >Sent: Monday, November 05, 2001 6:28 AM
> > >To: Aleks Sheynkman
> > >Cc: openldap-software@OpenLDAP.org
> > >Subject: Re: performance problem with sldap
> > >
> > >
> > >
> > >It would be possible that slapd went down running short of memory.
> > >The entry cache size looks large for 200K directory,
> > >even though slapd allocates cache entries on demand.
> > >The entry cache is designated as the number of entries
> > >while the db cache is as the number of bytes.
> > >- Jong
> > >=======================
> > >IBM T. J. Watson Research
> > >Enterprise Linux Group, Linux Technology Center
> > >jongchoi@us.ibm.com