[Date Prev][Date Next]
Re: (ITS#3851) Berkeley DB Scalability Patch
--On Wednesday, October 05, 2005 11:07 AM -0400 Jong-Hyuk
> 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
> 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
>> 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.
Packaged, certified, and supported LDAP solutions powered by OpenLDAP: