[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: slapadd going for a very long time
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@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
> >
>