Re: (ITS#3851) Berkeley DB Scalability Patch

[quanah@symas.com]

--On Wednesday, October 05, 2005 11:07 AM -0400 Jong-Hyuk 
<jongchoi@watson.ibm.com> wrote:

> Moving this to ITS. Comments inline.
>
>> This ITS mainly has to do with loading data into back-bdb, as opposed
>> to how it performs long term.  In my tests, I used a 1.7GB DB Cache,
>> indexing 21 attributes out of 28 attributes.
>
> As I have shown its search / search-update performance in this message
> (http://www.openldap.org/its/index.cgi/Development?id=3851;selectid=3851#
> followup6), it has a significant impact on the normal search / update
> workload as well as the directory population.

I suggest reading followup #1 where I show a 10 times worse performance 
with your patch.  Again, I think the fact that your test systems have large 
amounts of RAM beyond what you are setting the DB_CONFIG file are 
influencing your results, and are not reflective of real world resource 
starved systems.


>> My /db dir shows:
>>
>> 58M     carLicense.bdb
>> 648M    cn.bdb
>> 56M     departmentNumber.bdb
>> 444M    dn2id.bdb
>> 7.7M    employeeType.bdb
>> 335M    givenName.bdb
>> 444M    homePhone.bdb
>> 3.5G    id2entry.bdb
>> 24M     l.bdb
>> 57M     mail.bdb
>> 445M    mobile.bdb
>> 664K    o.bdb
>> 2.6M    objectClass.bdb
>> 664K    ou.bdb
>> 444M    pager.bdb
>> 42M     postalCode.bdb
>> 20M     preferredLanguage.bdb
>> 27M     roomNumber.bdb
>> 419M    sn.bdb
>> 20M     st.bdb
>> 443M    telephoneNumber.bdb
>> 56M     uid.bdb
>> 664K    userPassword.bdb
>>
>>
>>
>> All of my testing indicates that your DB_CACHE while running (not
>> slapadding) must be at least as big as your id2entry bdb file,
>> regardless of this patch.

> Again, numbers please.

I recently posted a discussion around this on the -devel list.  And Eric's 
on response agrees with my observations.

--Quanah

--
Quanah Gibson-Mount
Product Engineer
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>