Hi,
Thanks for the reply.
Using BDB backend
My DB_CONFIG:
set_verbose DB_VERB_DEADLOCK
set_verbose DB_VERB_RECOVERY
set_verbose DB_VERB_WAITSFOR
set_verbose DB_VERB_CHKPOINT
set_cachesize 0 536870912 0
set_lg_bsize 1048576
set_lg_regionmax 262144
set_lg_dir log
set_lk_detect DB_LOCK_RANDOM
#set_flags DB_TXN_NOSYNC
I'll try uncommenting the DB_TXN_NOSYNC line and see if it speeds up at all.
Thanks
M
On Jan 10, 2008 11:45 AM, Aaron Richton <richton(a)nbcs.rutgers.edu> wrote:
You'd think that your 250MB LDIF would fit entirely in your 1GB
RAM. Now,
there are certainly some bugs since 2.2.13 that prevent optimal
functioning, but let's (quite possibly unreasonably) look at the glass as
half full:
* Are you using bdb/hdb backends?
* Do you have an appropriate DB_CONFIG?
* I don't think there's a -q option in 2.2. You could consider set_flags
DB_TXN_NOSYNC to speed things up on the initial load.
On Thu, 10 Jan 2008, Lionel Kernux wrote:
> Hi all,
>
> I realize that the versions to which I am going to refer are somewhat
> deprecated so please bear with me.....
> 2.2.13
> I'm running RHEL4 and am bound by policy to only use RHEL4 packages so
> this is why I am only using v2.2.13.
>
> Anyway...
>
> I need to add a new slave to the pool of LDAP servers. I ran slapcat
> -l /tmp/myfile.ldif on the master.
>
> Then copied the resultant ldif to the new slave.
>
> Then ran slapadd -v -l myfile.ldif
>
> myfile.ldif is ~250MB and the source LDAP directory contains #
> numEntries: 427839
>
> I started the slapadd 20 hours ago and it is still running....
>
> Is this normal, given the number of entries?
>
> Machine is Dell Poweredge 1750
> Xeon 2.4GHz X 2
> 1024MB RAM
> 36GB RAID5
>
>
> Thankx
>
> M
>