tidy.

[openldap] / doc / guide / admin / tuning.sdf

diff --git a/doc/guide/admin/tuning.sdf b/doc/guide/admin/tuning.sdf
index 486aef445aacb8a78913fe61d3a3947ad2505569..28baa9624f60405ce18476607b585a7828970f22 100644 (file)
--- a/doc/guide/admin/tuning.sdf
+++ b/doc/guide/admin/tuning.sdf
@@ -78,7 +78,7 @@ General rule: don't go overboard with indexes. Unused indexes must be maintained
 See {{slapd.conf}}(8) and {{slapdindex}}(8) for more information
 
 
-H3: Presense indexing
+H3: Presence indexing
 
 If your client application uses presence filters and if the
 target attribute exists on the majority of entries in your target scope, then
@@ -146,7 +146,7 @@ if you are using the default LOCAL4 logging you could try:
 
 For syslog-ng, add or modify the following line in {{syslog-ng.conf}}:
 
-   options { sync(n); };
+>   options { sync(n); };
 
 where n is the number of lines which will be buffered before a write.
 
@@ -214,7 +214,7 @@ check this number for both dn2id and id2entry.
 Also note that {{id2entry}} always uses 16KB per "page", while {{dn2id}} uses whatever 
 the underlying filesystem uses, typically 4 or 8KB. To avoid thrashing the, 
 your cache must be at least as large as the number of internal pages in both 
-the {{dn2id}} and {{id2entry}} databases, plus some extra space to accomodate the actual 
+the {{dn2id}} and {{id2entry}} databases, plus some extra space to accommodate the actual 
 leaf data pages.
 
 For example, in my OpenLDAP 2.4 test database, I have an input LDIF file that's 
@@ -300,13 +300,13 @@ A default config can be found in the answer:
 just change the set_lg_dir to point to your .log directory or comment that line.
 
 Quick guide:
-- Create a DB_CONFIG file in your ldap home directory (/var/lib/ldap/DB_CONFIG) with the correct "set_cachesize" value
-- stop your ldap server and run db_recover -h /var/lib/ldap
-- start your ldap server and check the new cache size with:
+* Create a DB_CONFIG file in your ldap home directory (/var/lib/ldap/DB_CONFIG) with the correct "set_cachesize" value
+* stop your ldap server and run db_recover -h /var/lib/ldap
+* start your ldap server and check the new cache size with:
 
   db_stat -h /var/lib/ldap -m | head -n 2
 
-- this procedure is only needed if you use OpenLDAP 2.2 with the BDB or HDB backends; In OpenLDAP 2.3 DB recovery is performed automatically whenever the DB_CONFIG file is changed or when an unclean shutdown is detected.
+* this procedure is only needed if you use OpenLDAP 2.2 with the BDB or HDB backends; In OpenLDAP 2.3 DB recovery is performed automatically whenever the DB_CONFIG file is changed or when an unclean shutdown is detected.
 
 
 --On Tuesday, February 22, 2005 12:15 PM -0500 Dusty Doris <openldap@mail.doris.cc> wrote:
@@ -334,7 +334,7 @@ It will consume the memory resources of your system, and likely cause issues.
 
 I try to cache the most actively used entries. Unless you expect all 400,000 entries of your DB to be accessed regularly, there is no need to cache that many entries. My entry cache is set to 20,000 (out of a little over 400,000 entries).
 
-The idl cache has to do with how many unique result sets of searches you want to store in memory. Setting up this cache will allow your most frequently placed searches to get results much faster, but I doubt you want to try and cache the results of every search that hits your system. ;)
+The idlcache has to do with how many unique result sets of searches you want to store in memory. Setting up this cache will allow your most frequently placed searches to get results much faster, but I doubt you want to try and cache the results of every search that hits your system. ;)
 
 --Quanah