Re: slapadd/bdb tuning newbie

[Gary LaVoy <glavoy@apple.com>]

Thanks Howard,

> > I am running openldap 2.1.22 and BDB 4.1.(latest) as this is what 
> > ships currently on OS X 10.3 stock. Xserve 1.0 Gh Dual CPU with 2 Gb 
> > RAM.
>
> That's too bad. There's easily 80 or so bug fixes between 2.1.22 and 
> the current (2.1.30) release, countless fixes between 2.1.X and 2.2. 
> Perhaps your vendor needs help staying up to date. (Oh, wait, you 
> *are* the vendor. Hm...)

Yes, but I am not in the group that ships this stuff. I am just trying 
to use it out of the box and admittedly it was not intended to scale to 
millions of records when 2.1.22 was put in there. I can retry with 
2.2.13 if I have to, and probably will (however I'd prefer not to 
repeat my 52 hour ordeal - so I guess I better get on the tuning stick 
huh?!)

> > Here is the slapd.conf entry for that DB that I set up (I have 3 
> > separate DB in the file) (yes I need all those indexes)
> > database bdb
> > suffix "o=Apple"
> > rootdn "cn=Manager,o=apple"
> > directory /ngs/app/openldap2/apple_openldap/var/openldap-data/db/apple
>
> > and here is the DB_CONFIG I used:
> > (I picked these based on a first attempt to get it to be faster than 
> > with no config since everything I have ever read says you better have 
> > one.)
> > #
> > # Set the database in memory cache size.
> > #
> > set_cachesize 0 52428800 0
>
> Now that you've invested those 52 hours in loading this thing, did you 
> look at db_stat to see how well this cache performed? Have you looked 
> at the stats on the individual database files to see how many pages 
> they each consume? It seems, given your 2GB RAM available, that the 
> 52MB you've configured here is rather miserly. But without knowing the 
> overall data volume you're dealing with, it's impossible to draw any 
> conclusions.

No, I could bump that up. I have 2 bdb db's defined in my slapd.conf 
and 3 DB_CONFIGS (1 for each - is this not what I should be doing?)

So I set the cache to be 52M in 2 of them and 134M in the last one 
(that was the one that took 52 hours).

Then I have
cachesize       10000
cachesize       5000
cachesize       20000

set in slapd.conf for each of these db's respectively. I am not sure 
how the cachesize in slapd.conf and DB_CONFIG work with each other, if 
at all, so I didn't want the addition of all these to be too large.

Maybe setting set_cachesize 0 500000000 0 for each would still be under 
my total real RAM limit and help out?

It was a starting point.

I am not that versed with the db_* utils for BDB yet, so I will dig 
around with db_stat and see what it says. I am trying to get myself off 
my old installation which is running with ldbm. bdb requires you to 
understand much more about what is going on with your database (and, 
yes damnit, I should understand this! :-)

> > # Set log values.
> > #
> > set_lg_regionmax 1048576
> > set_lg_max 10485760
> > set_lg_bsize 2097152
> > set_lg_dir 
> > /ngs/app/openldap2/apple_openldap/var/openldap-data/db/txlogs/apple
>
> Have you actually mounted a separate disk under this directory path? 
> As the docs state in several places, you need to put the logs on a 
> physically separate spindle from the database files to get the best 
> performance. Otherwise, just realize that however large your input 
> data is, your single disk needs to handle double-to-triple that data 
> volume because all of the data and all of the logs are going on the 
> same disk, and there's a ton of seek overhead along with it all. Not 
> even RAIDs perform well in the face of heavy random access patterns...

Well, our standard config is xserve with 4 drives, 2 software mirrored 
for the system disk (apps not allowed to live on there) and 2 software 
mirrored for the "application" space (yes, sw mirroring adds yet 
another level of performance hit, but I am just trying to live on what 
our datacenter standards are to start then ask for exceptions where 
necessary.

And, yes, the logs and the db are on the same disk. for development 
purposes I can move them to a space on the system disk since I own root 
on the box just to see how much improvement I can get. If it's really 
significant I can request this for production as an exception (where 
app teams do not have root)

> > set_tmp_dir /tmp
>
> The BDB library doesn't use temporary files in back-bdb, so this 
> setting is pointless.


Great. I'll dump it.