Is there some way to speed up LDAP? I am guessing this has to do with it searching the database on ldap? This is a new server and my old one did not take that long. It is not as slow if just one or two people are logging in with ldap, but when many login, it seems to bring ldap to a bottle neck, I guess while searching the directory for all the names.
There are probably about 1000 users in my LDAP. Is that too large? I assume it isn't since most of the other schools around have AD which is basically Microsoft LDAP if I understand correctly and they have no problems and have many more users than I have.
Can multiple schema's in the config file cause this? I know that on my old server I had the following in slapd.conf:
core cosine inetorgperson nis samba
On my new one it has the above plus:
corba duaconf dyngroup java misc openldap ppolicy collective
Those were just in there when I installed it so I left them. Should I take them out or would that not have any affect on logins at all? I am guessing that they wont' affect anything and it is more related to some sort of configuration in my ldap configs.
Is there something else I need in a config? Here are my configs. slapd.conf include /etc/openldap/schema/corba.schema include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/duaconf.schema include /etc/openldap/schema/dyngroup.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/java.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/ppolicy.schema include /etc/openldap/schema/collective.schema include /etc/openldap/schema/samba.schema loglevel -1 sizelimit -1 allow bind_v2 pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args database bdb suffix "dc=school,dc=bloomfield.k12.mo.us" checkpoint 1024 15 rootdn "cn=Manager,dc=school,dc=bloomfield.k12.mo.us" rootpw ***** directory /var/lib/ldap index objectClass eq index cn,sn,uid,displayName eq,pres,sub index uidNumber,gidNumber eq index memberUid eq index sambaSID,sambaPrimaryGroupSID eq index sambaDomainName eq index default sub database monitor
ldap.conf SIZELIMIT 200 HOST 127.0.0.1 10.0.0.5 BASE dc=school,dc=bloomfield.k12.mo.us
I have a DB_CONFIG file that contains the following, but not sure if it needs anything else or not:
set_cachesize 0 268435456 1 set_lg_regionmax 262144 set_lg_bsize 2097152
Thanks for any info.
--On Sunday, August 30, 2009 5:04 PM -0500 sgmayo@mail.bloomfield.k12.mo.us wrote:
Is there some way to speed up LDAP? I am guessing this has to do with it searching the database on ldap? This is a new server and my old one did not take that long. It is not as slow if just one or two people are logging in with ldap, but when many login, it seems to bring ldap to a bottle neck, I guess while searching the directory for all the names.
There are probably about 1000 users in my LDAP. Is that too large? I assume it isn't since most of the other schools around have AD which is basically Microsoft LDAP if I understand correctly and they have no problems and have many more users than I have.
I use OpenLDAP with tens of millions of users. It's quite responsive. See comments below.
Can multiple schema's in the config file cause this? I know that on my old server I had the following in slapd.conf:
core cosine inetorgperson nis samba
On my new one it has the above plus:
corba duaconf dyngroup java misc openldap ppolicy collective
Those were just in there when I installed it so I left them. Should I take them out or would that not have any affect on logins at all? I am guessing that they wont' affect anything and it is more related to some sort of configuration in my ldap configs.
Is there something else I need in a config? Here are my configs. slapd.conf include /etc/openldap/schema/corba.schema include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/duaconf.schema include /etc/openldap/schema/dyngroup.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/java.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/ppolicy.schema include /etc/openldap/schema/collective.schema include /etc/openldap/schema/samba.schema loglevel -1
Fix your loglevel. Try 256 or something else reasonable. Are you running Xen?
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
Can multiple schema's in the config file cause this? I know that on my old server I had the following in slapd.conf:
core cosine inetorgperson nis samba
On my new one it has the above plus:
corba duaconf dyngroup java misc openldap ppolicy collective
Those were just in there when I installed it so I left them. Should I take them out or would that not have any affect on logins at all? I am guessing that they wont' affect anything and it is more related to some sort of configuration in my ldap configs.
Is there something else I need in a config? Here are my configs. slapd.conf include /etc/openldap/schema/corba.schema include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/duaconf.schema include /etc/openldap/schema/dyngroup.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/java.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/ppolicy.schema include /etc/openldap/schema/collective.schema include /etc/openldap/schema/samba.schema loglevel -1
Fix your loglevel. Try 256 or something else reasonable.
I'll try that tomorrow and see. My old server had that and it did not slow things down like this, but I am willing to try anything right now. Hopefully that will take care of it. I will let you know.
Are you running Xen?
No, not sure what that is even.
Thanks for the input.
Quanah Gibson-Mount wrote:
Fix your loglevel. Try 256 or something else reasonable. Are you
running
Xen?
Thank you very much. That seems to have taken care of the terrible lag problems when everyone logged in. You have made my whole staff as well as the students much happier.
I am now waiting for my server to totally crash because that problem was far too easy to fix. Nothing is ever that simple for me. ;)
Thanks again.
Hi all, a question about the syncrepl cookie. 2.4.17, on linux, in a multimaster mode with 2 nodes.
We're running a test where we remove data and add data to the database through a c++ application (calling ldap_delete_ext_s() and ldap_add_ext_s(). The test begins with a freshly created slapd database that has an empty tree (i.e, no nodes exist below a starting node (lcc=lcc1, ou=Company, o=CMP). The test proceeds in these steps: 1) add in a small number of nodes and subnodes to (A); 2) wait for the tree to replicate to (B) 3) remove the tree from (A) 4) wait for the tree to be removed from (B). This repeats several times.
We always run this test on one node (A) and just look to make sure replication is working on the other node (B)
What we're seeing is the following behavior on A: If we run this test through many cycles without restarting slapd on either node, everything works as expected.
If we shut down slapd and restart it on (A) after some cycle (at the end of step 4) then we begin to see many messages in the log file similar to the following, for multiple nodes: syncprov_search_response: Entry ou=Wrapup,lcc=lcc1,ou=Company,o=CMP changed by peer, ignored
And, on (B), the nodes that on (A) have this message, are there but their organizationalUnit=glue
The difference, as far as I can tell, comes down to this line in syncprov.c(about line 2160): if ( sid == srs->sr_state.sid && srs->sr_state.numcsns ) { Debug( LDAP_DEBUG_SYNC, "Entry %s changed by peer, ignored\n", rs->sr_entry->e_name.bv_val, 0, 0 );
I log the value of srs->sr_stat.numcsns. When I don't restart slapd, the value of numcsns is 0 (since there is no cookie in the db); after I restart slapd the value is 1 (this is the value read from the cookie in the db). I've also logged the value of numcsns when the cookie is written when it is checkpointed, it is 1.
I'm thinking this is a bug in the code. The only difference in the two types of runs is that slapd is restarted on (A), and only restarted after sync is complete and both systems are quiescent.
Sorry, I meant to put a different title on this submission.
-----Original Message----- From: openldap-technical-bounces+robert.hanson=calabrio.com@OpenLDAP.org [mailto:openldap-technical-bounces+robert.hanson=calabrio.com@OpenLDAP.org] On Behalf Of Robert Hanson Sent: Monday, August 31, 2009 6:15 PM To: openldap-technical@openldap.org Subject: RE: Slow LDAP
Hi all, a question about the syncrepl cookie. 2.4.17, on linux, in a multimaster mode with 2 nodes.
We're running a test where we remove data and add data to the database through a c++ application (calling ldap_delete_ext_s() and ldap_add_ext_s(). The test begins with a freshly created slapd database that has an empty tree (i.e, no nodes exist below a starting node (lcc=lcc1, ou=Company, o=CMP). The test proceeds in these steps: 1) add in a small number of nodes and subnodes to (A); 2) wait for the tree to replicate to (B) 3) remove the tree from (A) 4) wait for the tree to be removed from (B). This repeats several times.
We always run this test on one node (A) and just look to make sure replication is working on the other node (B)
What we're seeing is the following behavior on A: If we run this test through many cycles without restarting slapd on either node, everything works as expected.
If we shut down slapd and restart it on (A) after some cycle (at the end of step 4) then we begin to see many messages in the log file similar to the following, for multiple nodes: syncprov_search_response: Entry ou=Wrapup,lcc=lcc1,ou=Company,o=CMP changed by peer, ignored
And, on (B), the nodes that on (A) have this message, are there but their organizationalUnit=glue
The difference, as far as I can tell, comes down to this line in syncprov.c(about line 2160): if ( sid == srs->sr_state.sid && srs->sr_state.numcsns ) { Debug( LDAP_DEBUG_SYNC, "Entry %s changed by peer, ignored\n", rs->sr_entry->e_name.bv_val, 0, 0 );
I log the value of srs->sr_stat.numcsns. When I don't restart slapd, the value of numcsns is 0 (since there is no cookie in the db); after I restart slapd the value is 1 (this is the value read from the cookie in the db). I've also logged the value of numcsns when the cookie is written when it is checkpointed, it is 1.
I'm thinking this is a bug in the code. The only difference in the two types of runs is that slapd is restarted on (A), and only restarted after sync is complete and both systems are quiescent.
--On Monday, August 31, 2009 6:18 PM -0500 Robert Hanson Robert.Hanson@calabrio.com wrote:
Sorry, I meant to put a different title on this submission.
-----Original Message----- From: openldap-technical-bounces+robert.hanson=calabrio.com@OpenLDAP.org [mailto:openldap-technical-bounces+robert.hanson=calabrio.com@OpenLDAP.or g] On Behalf Of Robert Hanson Sent: Monday, August 31, 2009 6:15 PM To: openldap-technical@openldap.org Subject: RE: Slow LDAP
Hi all, a question about the syncrepl cookie. 2.4.17, on linux, in a multimaster mode with 2 nodes.
I would suggest you file an ITS on this issue.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org
-
Quanah Gibson-Mount -
Robert Hanson -
sgmayo＠mail.bloomfield.k12.mo.us