[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: DB_CONFIG
Turbo Fredriksson disse:
>
> From this, I asume that my calculation would look like this:
>
> File: /var/lib/ldap/dn2id.bdb
> 4096 Underlying database page size.
> 1 Number of tree internal pages.
> 18 Number of tree leaf pages.
> => ((1+1)*4096) => 40960
I would say 2*4096 = 8192 bytes
>
> +
>
> File: /var/lib/ldap/id2entry.bdb
> 16384 Underlying database page size.
> 1 Number of tree internal pages.
> 27 Number of tree leaf pages.
> => ((1+1)*16384) => 32768
>
>
> Resulting in the value 73728 (73Mb). Correct values used?
Resulting in 40960 bytes. You're mixing up Kbytes and bytes. So it's only
40Kbytes
>
> Considering that my id2entry.bdb file is only 491520 bytes
> and dn2id.bdb is 86016 bytes, I find it odd that I have to
> to use a HUMONGOUSLY bigger cache than [whoever wrote FAQ
> entry #1075]... Or did I missread '73728'?
>
>
> Followup question 2: It said on the page that one should
> take into account any indexes...
>
> The calculation example looks like this:
>
> The objectClass index for my example database is 5.9MB and uses 3 hash
> buckets and 656 duplicate pages. So ( 3 + 656 ) * 4KB / 2 =~ 1.3MB.
>
> Where did the '3' come from? Can't see any references to 'hash' or
> 'bucket' in the output from db_stat...
The underlying structure for indexes has changed from Hash to Btree so
that part no longer applies.
>
> ----- s n i p -----
> [papadoc.root]# db4.2_stat -h /var/lib/ldap -d
> /var/lib/ldap/objectClass.bdb
> 53162 Btree magic number.
> 9 Btree version number.
> Flags: duplicates, little-endian
> 2 Minimum keys per-page.
> 4096 Underlying database page size.
> 2 Number of levels in the tree.
> 25 Number of unique keys in the tree.
> 1021 Number of data items in the tree.
> 1 Number of tree internal pages.
> 4020 Number of bytes free in tree internal pages (2% ff).
> 3 Number of tree leaf pages.
> 4502 Number of bytes free in tree leaf pages (63% ff).
> 2 Number of tree duplicate pages.
> 4160 Number of bytes free in tree duplicate pages (49% ff).
> 0 Number of tree overflow pages.
> 0 Number of bytes free in tree overflow pages (0% ff).
> 0 Number of pages on the free list.
> ----- s n i p -----
>
>
> I wrote a perl script (included if it's correct and someone
> needs something similar) that does the calculation for me...
>
> Running this on my system tell me to use a cache size of
> 114Mb (I used 52Mb previosly which might explain things!!).
>
> Provided this value is correct, what if I enter '150Mb' as
> cache, and i get a boost in subscriptions (I'm using this
> db as email/user db) and 150Mb isn't enough!? How can I
> grow the cache 'live', without reloading the db? Is this
> possible?
>
>
> It say that I can use 'db_stat -m' to "check how well the
> database cache is performing"... Sure, but what am I'm
> looking at!?
>
>
> Sorry for all these questions about something that isn't
> OpenLDAP but rather BerkeleyDB, but their documentation
> (conserning DB_CONFIG and db_stat) really sucks. It's
> even worse than the OpenLDAP one :)
>
> If you (someone) help me out here, I promise I'll write
> down something fancy that people can actually understand :)
>
>
--
Luca Scamoni - e-mail: luca.scamoni@sys-net.it
SysNet snc - Via Dossi, 8 - 27100 Pavia Italy
IT Senior Consultant - mobile: +393471014425
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497