Edward "Koko" Konetzko wrote: > Rich Megginson wrote: >> Edward "Koko" Konetzko wrote: >>> I have a set of CoS objects I am importing in and their add times >>> are extremely slow about 1 a second. >> What platform? What 389-ds-base version? By import do you mean >> ldif2db or ldap add? > RHEL 5 64 bit, RHDS 8.1 and using ldapadd. Hardware is HP DL385 with > 16 gigs of ram, raid1 for os and raid 10 for /var/lib/dirsrv. I have > tried with the import buffer(?) set to auto and 2 gigs. Since you are using Red Hat Directory Server, you should contact Red Hat support. import buffer is only when using ldif2db. LDAP Add is much slower than ldif2db. I think part of it is that CoS is optimized for searching, but not so much for adding new CoS definitions - it builds a cache in memory to make searches go very quickly, but building the cache takes time during each add or modify operation. >>> There are about 500k objects in the directory currently and its >>> broken down in a hierarchical format. >>> A simple ASCII drawing would be. >>> >>> ou=top >>> | >>> - ou=First >>> | >>> + ou=Second >>> | >>> + cn=Final >>> >>> >>> This is representation of the data but for ease of explanation this >>> should work. >>> >>> There are lots of "First" object and they have the possibility of >>> lots of "second" objects. Its the also the same for "Second" object >>> they could have a lot of "Final" objects. The idea is to use CoS at >>> the First and Second level to reduce the amount look ups and >>> redundant data as final objects need some info from the second >>> objects and first objects. >>> Hopefully I explained that in a way it is easy to understand. >>> >>> My question is are CoS objects not supposed to be used this way? >>> Also are lots of CoS objects used in a hierarchical tree this way >>> bad? Is there a way to make these imports faster? And last am I >>> just doing something completely wrong and there is a better way that >>> I should work to my end goal. >>> >>> Thanks >>> Edward >>> >>> >>> >>> -- >>> 389 users mailing list >>> 389-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-directory-users >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20091203/014f8a27/attachment.bin
