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
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.
I'm sorry for you.
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?
Did you create a DB_CONFIG file?
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
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
--On Thursday, January 10, 2008 11:01 AM -0500 Lionel Kernux lionel.kernux@gmail.com 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.
Seriously reconsider your policy, it is amazingly flawed. The RHEL4 packages are not meant to be used for OpenLDAP as a server, they are provided for the client libraries.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
On Thursday 10 January 2008 18:01:12 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.
I also use RHEL4 packages, but not ones that come from Red Hat, ones I build for RHEL4:
http://staff.telkomsa.net/packages/
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
On similar hardware, (1750 with 2GB ram, 36GB in RAID1 with a hot spare), but with approximately the same cachesize in DB_CONFIG (as there are other databases), one of our similarly sized databases (~ 450 000 entries, ~420MB of raw ldif), takes less than two hours to import (on 2.3.x). I don't have stats for 2.2.
Regards, Buchan
Buchan Milne wrote:
On Thursday 10 January 2008 18:01:12 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.
If your policy requires you to use packages as supplied by a particular vendor it would make sense for your policy to also require that vendor to support those packages. I.e., go to RedHat and make them earn the fees you're paying them. If they don't help you, then you should seriously reconsider why you're paying them in the first place...
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
On similar hardware, (1750 with 2GB ram, 36GB in RAID1 with a hot spare), but with approximately the same cachesize in DB_CONFIG (as there are other databases), one of our similarly sized databases (~ 450 000 entries, ~420MB of raw ldif), takes less than two hours to import (on 2.3.x). I don't have stats for 2.2.
Best case for 2.2 slapadd was 2x slower than 2.3. Worst case depended how much indexing was configured.
openldap-software@openldap.org
-
Aaron Richton -
Adam Tauno Williams -
Buchan Milne -
Howard Chu -
Lionel Kernux -
Quanah Gibson-Mount