Hello,
We have a openldap (2.3.30, debian etch version 32bits) with 4 nodes (xen vm with one cpu core, Intel Xeon 3.20GHz and 2GB of RAM). It that farm we have two databases one with 121K entries (for authenticating users, with lots of connections) and other with 40K entries (with public information of our students, for example).
Now we have migrated to two openldap (2.4.21, ubuntu lucid 64btis) farms. One with 4 nodes (xen vm with two cpu cores, Xeon E5450 3GHz, 2 GB of RAM) for the authentication database, and other with 2 nodes (with the same resources than the other) for the other database.
The problem is that in the authentication farm we are having lot of problems due to heavy load, although we are not completely migrate all clients to this new farm (we already have clients querying the old farm), but in the old farm we didn't have any problem (just some punctual problems long time ago).
The only difference between the old and the new farm is that the old farm was replicating information with slurpd. The new one is a multimaster configuration. The configuration of the replica is:
mirrormode on syncrepl rid=11 provider="ldap://<server1>.um.es" binddn="<replica user dn>" bindmethod=simple credentials=<creds> searchbase="<base of database>" type=refreshAndPersist interval=00:00:00:10 retry="5 5 300 +" timeout=1
syncrepl rid=12 provider="ldap://<server2>.um.es" binddn="<replica user dn>" bindmethod=simple credentials=<creds> searchbase="<base of database>" type=refreshAndPersist interval=00:00:00:10 retry="5 5 300 +" timeout=1
syncrepl rid=13 provider="ldap://<server3>.um.es" binddn="<replica user dn>" bindmethod=simple credentials=<creds> searchbase="<base of database>" type=refreshAndPersist interval=00:00:00:10 retry="5 5 300 +" timeout=1
syncrepl rid=14 provider="ldap://<server4>.um.es" binddn="<replica user dn>" bindmethod=simple credentials=<creds> searchbase="<base of database>" type=refreshAndPersist interval=00:00:00:10 retry="5 5 300 +" timeout=1
This configuration is in the 4 farm nodes. We have checked indexes and both farms have the same.
Another difference is that authentication database entries have some attributes obtained from the other database via dynlist overlay. In the old farm, because the two databases are in the same server we had no problem, but in the new one we have to configure this database as an ldap proxy to the other farm, with cache overlay used in this.
Heavy loads appears randomly in all nodes (not always with all nodes at the same time). When this happens, slapd is using 100% (well... top reports 200% because we have two cpus), there is no swap, no iowait....
Any idea of what could it be the problem? Is this multimaster configuration so heavy load?
--On Friday, January 13, 2012 10:55 AM +0100 "Angel L. Mateo" amateo@um.es wrote:
Now we have migrated to two openldap (2.4.21, ubuntu lucid 64btis) farms. One with 4 nodes (xen vm with two cpu cores, Xeon E5450 3GHz, 2 GB of RAM) for the authentication database, and other with 2 nodes (with the same resources than the other) for the other database.
OpenLDAP 2.4.21 is over 2 years old. I would first suggest upgrading to a current release, given the hundreds of bug fixes since then. If you still see load issues, I highly advise reading over http://wiki.zimbra.com/wiki/OpenLDAP_Performance_Tuning.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
El 13/01/12 21:34, Quanah Gibson-Mount escribió:
--On Friday, January 13, 2012 10:55 AM +0100 "Angel L. Mateo" amateo@um.es wrote:
Now we have migrated to two openldap (2.4.21, ubuntu lucid 64btis) farms. One with 4 nodes (xen vm with two cpu cores, Xeon E5450 3GHz, 2 GB of RAM) for the authentication database, and other with 2 nodes (with the same resources than the other) for the other database.
OpenLDAP 2.4.21 is over 2 years old. I would first suggest upgrading to a current release, given the hundreds of bug fixes since then. If you still see load issues, I highly advise reading over http://wiki.zimbra.com/wiki/OpenLDAP_Performance_Tuning.
I'd already followed the db tuning (but not the shared memmory). I'll take a look on this.
On Fri, 13 Jan 2012, Angel L. Mateo wrote: ...
The only difference between the old and the new farm is that the old farm was replicating information with slurpd. The new one is a multimaster configuration. The configuration of the replica is:
...
This configuration is in the 4 farm nodes. We have checked indexes and both farms have the same.
You have the exact same indexes on your new syncrepl-based systems as you did on your old slurpd-based systems? If so, then you probably don't have equality indexes on entryCSN and entryUUID, which will make syncrepl's internal searches much slower and inefficient than they can be.
Philip Guenther
El 13/01/12 22:43, Philip Guenther escribió:
On Fri, 13 Jan 2012, Angel L. Mateo wrote: ...
The only difference between the old and the new farm is that the old farm was replicating information with slurpd. The new one is a multimaster configuration. The configuration of the replica is:
...
This configuration is in the 4 farm nodes. We have checked indexes and both farms have the same.
You have the exact same indexes on your new syncrepl-based systems as you did on your old slurpd-based systems? If so, then you probably don't have equality indexes on entryCSN and entryUUID, which will make syncrepl's internal searches much slower and inefficient than they can be.
I have the same indexed than the old farm, plus indexes on entryCSN and entryUUID.
openldap-technical@openldap.org