[Date Prev][Date Next]
Re: slapadd going for a very long time
Thanks for the reply.
Using BDB backend
set_cachesize 0 536870912 0
I'll try uncommenting the DB_TXN_NOSYNC line and see if it speeds up at all.
On Jan 10, 2008 11:45 AM, Aaron Richton <email@example.com> 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