[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Slow adding attributes to a entry with many attributes



--On Friday, December 02, 2005 9:30 AM -0200 Ariel Malves <almalves@gmail.com> wrote:

Dear list.

In the past 4 days I have had problems with OpenLdap, running a Samba
PDC solution.

My PDC has about 3000 users, migrated from a Netware 5 with
eDirectory. Each user is in a primary and a secondary group too
(Students and Domain Users groups). I could see a very fast increasing
of log size (log.000000*) when adding users to secondary groups. For
each new memberUID attribute added to the group, the log grows about 7
mb! The time for this operation is very bad too, about 3 seconds.

Searching in archive of this list I found a message from other user
with same problem (
http://www.openldap.org/lists/openldap-software/200407/msg00446.html),
and the recommendation was to upgrade the version of OpenLdap to 2.2.*
and BDB to 4.2.52, but I already have those versions in my Debian
Sarge (stable).

Well, my question is: Is this normal?

I have tried changing the backend from bdb to hdb with slapcat &
slapadd, but nothing changed.

The only little performance improvement was when I create a DB_CONFIG
with the following attributes:

set_cachesize 0 300000000 10
set_lg_regionmax 262144

set_lg_bsize 2097152


set_flags DB_TXN_WRITE_NOSYNC

I tried another simulation in a clean ldap installation, creating a
unique person (inetOrgPerson) and adding many (2000+) mail addresses
to it and the results was similar: an intensive I/O on logs and the
operation of adding new attributes slowing down each time.

I have thought about a workaround: don't put these students in a
secondary group, but manage rights access to files would become
difficult a bit.

Please, if anyone has an idea, tell me.

Thanks to all, and sorry my poor English.

You haven't separated the BDB logs directory from the database directory by putting it onto a separate HD or spindle. There are known performance problems with having the logs and directory in the same location, since they both have to do writes at the same time.

See <http://www.stanford.edu/services/directory/openldap/configuration/bdb-config.html>

I will also note that 10 cache areas is very excessive, and testing in the past has indicated the more regions you create, the worse performance gets. There is no need to subdivide into further regions until you exceed the 4GB upper limit in BDB 4.2 or BDB 4.3. With BDB 4.4, on a 64 bit platform, there is no reason to subdivide at all.

I'd also suggest you figure out what exactly you need in terms of a cache size, the above link should be helpful for that as well. In addition, I'd use bdb over hdb in 2.2, but they are both fine in 2.3.


--Quanah



--
Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html