There may be several attributes of interest to you as far as the memory consumption is concerned (http://www.redhat.com/docs/manuals/dir-server/8.1/cli/Configuration_Command_File_Reference-Plug_in_Implemented_Server_Functionality_Reference-Database_Plug_in_Attributes.html) :
nsslapd-dbcachesize
nsslapd-cachememsize for every backend (by default, your data is in cn=userRoot,cn=ldbm database,cn=plugins,cn=config)
nsslapd-import-cachesize (used only during ldif import)
You can adjust the corresponding values by monitoring the attributes like currententrycachesize or entrycachehitratio of cn=monitor,cn=userRoot,cn=ldbm database,cn=plugins,cn=config (http://www.redhat.com/docs/manuals/dir-server/8.1/cli/Configuration_Command_File_Reference-Plug_in_Implemented_Server_Functionality_Reference-Database_Plug_in_Attributes.html#Configuration_Command_File_Reference-Database_Plug_in_Attributes-Database_Attributes_under_cnmonitor_cnldbm_database_cnplugins_cnconfig)
2009/6/26 Tim Hartmann <hartmann@xxxxxxxxxxxxxxx>
Hi!
I was spending some time today trying to make sure that I was getting the most bang for my buck today an my replica's and I notices two items of interest that I was wondering if anyone else had input on!
Firstly, after creating a number of indexs, my performance seems to be really good, the exception that I noticed was "finger" I noticed that finger takes a couple of seconds to return the data on RHDS whereas on OpenLDAP, it pops right now in real time! My first though was that I was doing an un-indexed search, but I can't for the life of me figure out what I might not be indexing that I should be!
The second thing I noticed was that on my servers, which are RHEL5, running 32bit OS's with the PAE Kernels, RHDS doesn't ever actually address more then 3 gig of ram! I was looking through the documentations, and it looks like by raising the "Maximum Cache Size" I'll be able to allow RHDS to use more of the available memory.. did I get that right?
Anyway, as always thanks in advance for all the help! This list has been a tremendous resource for an application that keeps on showing it's value in huge ways!
Best,
Tim
--
389 users mailing list
389-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
-- 389 users mailing list 389-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
